Probatch or Distributed Services Manager

Here is my suggested technique.  Basically you must write a script or program to run on the solver machine or use mine at your own risk. 🙂

1. CREO installed same build, same paths on solver machine and workstation(s).

2. Temp folder in the same location on solver machine and workstation(s)

3. shared network drive with same drive letter and path on all machines.

4. On solver machine start my custom script file from a folder on the shared drive.  (Simple CREO Continuous Batch Analysis.bat is the script and MyRemoteSolver could be the name of the folder it is in)

5. Submit jobs from workstation with directory for output files ON the shared drive and directory for temporary files to local path (C:\temp for example)  again the solver machine must have access to the shared drive and have the same name local path for temporary files. (these paths are shown or set in creo run settings)

6. Submit jobs by writing mecbatch1.bat (change the name from mecbatch.bat) write them directly in the same folder that the custom script was started from (MyRemoteSolver)  Additional jobs can be added as mecbatch2.bat, mecbatch3.bat, etc.

use a text editor to view any and all of the files I am including.  I recommend this to help learn how they work.

I am giving 2 WINDOWS versions of my solver scripts, both a simple one and a better, more detailed one.

The simple one does not do much other than just run the jobs submitted.

The more detailed has several useful features.

1. time delay to start (like if you don't want the solver to start until you leave for the day)

2. remote killing a job by just double clicking KILL_CURRENT_JOB.bat

3. displaying what process ID the batch solver is using.  This is useful so you kill the correct process if needed.

4. automatically killing a job that runs longer than the maximum allowed run time. (for example if you submit several jobs on the weekend you do not want a hang-up or unexpectedly long run on the first job to prevent it going on to other jobs.

5. log files and files to indicate status and the path to the current job.

I also use the path file to automatically view the report/status/and Pass files with a python/tkinter viewer that was developed by a colleague. I am unable to include that viewer at this time but it should not be too hard to replicate such a simple text viewer with an input path obtained from a file and 3 buttons to switch between the report/status/pass files.

There is some maintenance that needs to be done especially if jobs are killed because temporary folders will be left on the solver machine.  There could be conflicts or problems if those temporary folders have the same name as a newly submitted job.  Varying analysis names could also help with this issue (rather than always using default "Analysis1")

Hopefully this is what you were asking about.  Let me know if you have any questions about my technique.