[capucsc]

I'm looking for tips, tricks and general insights on building a generic simulation file structure for automated iterative design. I'm new to OF and to CFD, but have significant experience in automated design.

I'm looking at air flow over an object. Code external to OF will generate the structure for testing and write an STL file to disk. The STL will initially consist of only one solid. The geometry generated will have a maximum and minimum allowable size, and I need the case to accommodate anything within those limits.

This is my initial take on the process:
A python script will handle the overall process. It starts with a geometry description file. That file gets passed to a geometry builder which yields an STL. Python copies the generic OF file structure, assigns it a unique ID folder name and copies the STL into the proper directory. A bash script, which is stored in the copied template directory runs blockMesh, snappy and the solver. After the solver finishes (any easy way to detect?), the results will be processed and used to influence the next iteration of geometry design. This influence will be based on L/D and other parameters. I know that's high level, but are there any obvious places this process will break down?

Are there any examples of something similar to this? Right now, I have the geometry description file and the geometry builder done. I've been using discretizer and the OF tutorials to improve my understanding of how OF works but I still have a long way to go. I'm looking forward to your advice and would like to extend an invitation for collaboration, let me know if you're interested. Thanks in advance.

[Linse]

Hi Capucsc,

though I am unexperienced, up to now each of the runs of an OpenFOAM-solver did end with a note saying "End" in the output.
Maybe that is the initial step for you about knowing when you can start the next geometry iteration?

What I would suggest: Print the output of the solver into some log-file.
This logfile you might check all x seconds for the word "End".
As soon as that is found, you might call the reiteration loop for geometry.

Another possibility might be adding that very command at the point where the "End" message is issued within the solution routine. Where that exactly takes place, I don't know (yet)...

I am no programmer/informatics guy, so unfortunately I do not know about the very implementation in matters of source-code.

[mturcios777]

I have a case where I have to periodically remesh, with each different mesh begin stored in a different folder that covers a different span of time. For determining the end of a simulation, you don't really need to do that unless you are running multiple cases in parallel. Say if you're solver was icoFoam, and you run in your bash script:

 icoFOAM -case $PWD > foam.log

(if you need to log the results) then the console won't turn over control until that process is finished (so long as it isn't backgrounded); this should work no matter what method you use to stop the solver, though I am not very familiar with Python. When you call a bash script from python, does it wait until the end of the script before the next line of code?

[arjun]

IF you are on linux type system, expect and autoexpect are your best friends. They allow you to manage talk between various programs.
Have a look.

[capucsc]

Originally Posted by mturcios777

When you call a bash script from python, does it wait until the end of the script before the next line of code?

Yes it does, however, I think I would combine this with the log approach just for error checking.

Expect and autoexpect look very relevant to this problem. I'll try it out today.