[chriss85]

I'm using a custom solver coupled with a python script that solves some differential equations for boundary conditions. I use pyFoam to set the BCs. To get the values required for the ODEs I currently use patchIntegrate on a boundary. However, to speed things up I would like to include the functionality in the main solver, to avoid loading the fields again.

I was wondering if it was possible to use pyFoam to extract values from console output and either return them directly in the python script or write them to a csv that can be read easily.

I know it supports custom plots with customRegexp files. Right now I'm using the BasicRunner class to run my solver because I use custom plotting and I don't think (or know) that pyFoam plotters could deal with being executed separately for each step.

What's the best method here?

a) Write file from OpenFOAM instead of console output
b) Use pyFoam somehow?
c) Parse console output manually in pyFoam

On another note, when setting a boundary condition I noticed that I need to set it manually for each file in the processor directories in a parallel run. Is there a different, preferred method for doing this?

[chriss85]

I found the boundary condition externalCoupled (see here: http://foam.sourceforge.net/docs/cpp...0.html#details ), which can apparently be used for coupling with an external program.
This BC doesn't appear to be used in any of the tutorials, does anyone have a sample test case for it, together with a simple external application?

I would like to use it as it would provide me with a much better interfacing method, but I would like to avoid spending ages to figure out how it works if there is a working example already.

[gschaider]

Originally Posted by chriss85

I'm using a custom solver coupled with a python script that solves some differential equations for boundary conditions. I use pyFoam to set the BCs. To get the values required for the ODEs I currently use patchIntegrate on a boundary. However, to speed things up I would like to include the functionality in the main solver, to avoid loading the fields again.

I was wondering if it was possible to use pyFoam to extract values from console output and either return them directly in the python script or write them to a csv that can be read easily.

I know it supports custom plots with customRegexp files. Right now I'm using the BasicRunner class to run my solver because I use custom plotting and I don't think (or know) that pyFoam plotters could deal with being executed separately for each step.

What's the best method here?

a) Write file from OpenFOAM instead of console output
b) Use pyFoam somehow?
c) Parse console output manually in pyFoam

On another note, when setting a boundary condition I noticed that I need to set it manually for each file in the processor directories in a parallel run. Is there a different, preferred method for doing this?

So you (just that I understand this correctly)
- do a simulation
- do patchIntegrate to get the values
- read the values to do the ODE
- write the results to apply them to BCs (is this the same simulation as point 1?)

To get the values that patchIntegrate spits out into a timeline you could use pyFoamUtilityRunner.py to call it (with an appropriate regular expression). That file could be converted to CSV with pyFoamConvertToCSV.py (or a simple self-written script)

What I usually prefer to call patchAverage on the simulation data after it has finished is let a function object do that calculation during the simulation (I use swak4Foam)

[chriss85]

That's what I'm currently doing. It works, but it's somewhat ugly, as OpenFOAM needs to be restarted after each time step. Right now I'm working on adjusting my setup for the externalCoupled BC, I believe this should give some performance improvements and better precision (because the time steps of ODE and OF can then be the same, possibly using the minimum time step controlled by both programs).

Using a function object would probably give some small performance benefit over the external tool, right now I'm thinking of doing it directly in the solver and outputting the results to console.

[gschaider]

Originally Posted by chriss85

That's what I'm currently doing. It works, but it's somewhat ugly, as OpenFOAM needs to be restarted after each time step. Right now I'm working on adjusting my setup for the externalCoupled BC, I believe this should give some performance improvements and better precision (because the time steps of ODE and OF can then be the same, possibly using the minimum time step controlled by both programs).

Using a function object would probably give some small performance benefit over the external tool, right now I'm thinking of doing it directly in the solver and outputting the results to console.

OK. This is not for the faint of heart and I'm not quite sure if it fits your case: I don't know if you're aware of the Python-integration in swak4Foam. There the following would be possible:
- function Object evaluates values on a boundary. Feeds them into "global variables"
- function object with Python-interpreter does some calculation (using these variables). Gives back the results into global variables (Python-interpreter keeps its state so you can do some integration during the simulation)
- these global variables can then be used by groovyBC on the "target boundary"

I haven't done this exact thing yet with it but I don't see why it shouldn't be possible.
If you give it a try use the development version of swak4Foam. Python-integration is much better there (compared to the released version).
Parallel might be bit trickier because it might be necessary to make the Python-code parallel aware

[chriss85]

I haven't used swak4Foam yet, until now I have used pyFoam to write the boundary conditions after each time step, and then start OF from there again.

Have you checked out the externalCoupled BC in OF 2.2.2?
I have nearly completed modifying my python code for it now so I'll soon see how it works out. It also supports parallel computing apparently.
I'm only using it now to supply OF with the new BC values, the other direction, OF -> python will be handled through log parsing. Using a function object might still be a bit faster, but I believe that this should be negligible.

[gschaider]

Originally Posted by chriss85

I haven't used swak4Foam yet, until now I have used pyFoam to write the boundary conditions after each time step, and then start OF from there again.

Have you checked out the externalCoupled BC in OF 2.2.2?
I have nearly completed modifying my python code for it now so I'll soon see how it works out. It also supports parallel computing apparently.
I'm only using it now to supply OF with the new BC values, the other direction, OF -> python will be handled through log parsing. Using a function object might still be a bit faster, but I believe that this should be negligible.

No. Haven't looked at it yet. Nice. If you get over the "communication through the filesystem ... that is so Fortran"-part (but of course if you want to couple to a closed source code there hardly is another way). The reason why I usually avoid such approaches wherever possible is that there are a number of things that can go wrong (especially if you go from a local development machine to a production/cluster-system). For instance do a lot of batch queuing-systems only write the log in chunks (to minimize file-IO). So they might wait (for instance) until they have 4k of characters before they write to the log file. That is the output of more than one time-step. So if your script waits for the next time-script to appear in the log before it writes the new BC you might see a deadlock.

[chriss85]

Good point, I'll keep this in mind when this happens, I wasn't aware of that. However, using python it should be possible with subprocess.Popen() to monitor stdout without writing to disk, or is this buffered as well?

[chriss85]

I have encountered a design problem with the externalCoupled condition:

Basic structure of my solver:
-Outer electrical circuit described by ODEs that provides a potential
-Solver calculates current which is fed back in the ODEs to calculate potential for next time step

Now when I try to use the externalCoupled condition for the potential boundary, I was expecting that the locking would occur at the end of a time step. Instead, it happens directly after solving for the potential field. The solved field for the time step is written to data.out, OF deletes the lock file and waits for the external program to create data.in and recreate the lock.
However, this makes it impossible to extract the current from this time step, as it is obviously calculated after solving for the potential.

Now I think there are two possible methods:
- Also add a lock for the current field. I am not sure if this works because the current is not solved for, but calculated explicitly. Also the BC for the current needs to be calculated from the potential and conductivity BCs for correct results. I think this would also require to solve the potential equation twice, so that OF asks the external program for a new BC again after the current was calculated. This should not be much of an issue since the potential field should already be converged and there should not be much overhead.
- Manually create an lock in the solver at the end of the time step. I am not quite sure how to do this when the solver needs to run in parallel. Is it as simply as writing a file and checking for its existence? How to keep the cores in sync? I don't really know about the methods used in OF for parallelization.

Right now I'm a bit at a loss why this BC was created this way. Atleast for my case it would have been much more practical if the lock would occur at the start/end of a time step.

[gschaider]

Originally Posted by chriss85

Good point, I'll keep this in mind when this happens, I wasn't aware of that. However, using python it should be possible with subprocess.Popen() to monitor stdout without writing to disk, or is this buffered as well?

If the writing process believes that he is writing to a terminal it SHOULD be unbuffered (pyFoamRunner etc rely on this).

[gschaider]

Originally Posted by chriss85

I have encountered a design problem with the externalCoupled condition:

Basic structure of my solver:
-Outer electrical circuit described by ODEs that provides a potential
-Solver calculates current which is fed back in the ODEs to calculate potential for next time step

Now when I try to use the externalCoupled condition for the potential boundary, I was expecting that the locking would occur at the end of a time step. Instead, it happens directly after solving for the potential field. The solved field for the time step is written to data.out, OF deletes the lock file and waits for the external program to create data.in and recreate the lock.
However, this makes it impossible to extract the current from this time step, as it is obviously calculated after solving for the potential.

Now I think there are two possible methods:
- Also add a lock for the current field. I am not sure if this works because the current is not solved for, but calculated explicitly. Also the BC for the current needs to be calculated from the potential and conductivity BCs for correct results. I think this would also require to solve the potential equation twice, so that OF asks the external program for a new BC again after the current was calculated. This should not be much of an issue since the potential field should already be converged and there should not be much overhead.
- Manually create an lock in the solver at the end of the time step. I am not quite sure how to do this when the solver needs to run in parallel. Is it as simply as writing a file and checking for its existence? How to keep the cores in sync? I don't really know about the methods used in OF for parallelization.

Right now I'm a bit at a loss why this BC was created this way. Atleast for my case it would have been much more practical if the lock would occur at the start/end of a time step.

At the end of time-step is typically an application for a function-object. One way would be to let the functionObject do the communication and then get the field with lookupObject from the registry and override the boundary values with the ==-operator (the BC would be a normal fixedValue). You could do this in a coded-functionObject I guess.

[chriss85]

I have come up with a method to call the solve() twice for the electric potential equation. It's a bit hackish, but it should work without a performance impact because it's called one time after it is already solved, and so it should return quickly.

FunctionObject would also be a way I guess, I just haven't used it yet so I wasn't sure how to do it. If the current approach works then I'll likely stick to that.

[chriss85]

I wasn't able to use the externalCoupled boundary, as it produced some problems.
The boundaries had two value fields in the dictionaries, causing errors in paraview, and I also got unphysical solutions (though that may be caused by something else).

I have switched to a manual locking method in the solver and use a simple file format for exchanging data now. I'm aware that there are better methods (though I don't know exactly which, not too familiar with programming under Linux), but for now this should suffice.

This method has the advantage that it removes the need to parse log files to extract the results of the previous step.
Also, now that the solver is running continously, I can use pyFoamPlotRunner for plotting!


Thanks for your input!

[gschaider]

Originally Posted by chriss85

This method has the advantage that it removes the need to parse log files to extract the results of the previous step.
Also, now that the solver is running continously, I can use pyFoamPlotRunner for plotting!

That would always have been possible with a second terminal and pyFoamPlotWatcher.py