CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)
-   -   [swak4Foam] groovyBC storedVariables in parallel bugfix 9.6.3? (https://www.cfd-online.com/Forums/openfoam-community-contributions/165084-groovybc-storedvariables-parallel-bugfix-9-6-3-a.html)

Duncan_vdH January 9, 2016 09:49

groovyBC storedVariables in parallel bugfix 9.6.3?
 
If I understand correctly a groovyBC that is using storedVariables will cause a crash in parallel because the stored variable does not exist on all sub domains where the patch the groovyBC is set is not part of the boundary of the subdomain.

See:
https://openfoamwiki.net/index.php/C...oam/README_2.x

-------------
9.6.3 Bugfixes

9.6.3.1 Variables not working for parallel computations

If a variable is defined and the patch which it is defined on doesn't have any faces the variable is reported on that processor as not existing and the whole run fails

---------------


Is there a work around?



Best,
Duncan

Mehrez April 1, 2016 12:26

Hi,
Did you find a solution ?
I have the same issue.
Mhrz

Duncan_vdH April 1, 2016 15:47

Not completely.
I reformulated the boundary condition in terms of function objects that calculate global
variables. The global variables are than accessed by the groovy boundary condition on the only processor that actually contains that patch.

Now the computation does not crash anymore because it tries to set a boundary condition on a patch that is not available on that processor.

But the global variables are computed on each processor separately and
there is no variable that is truly global for all processors simultaneously.

For example, one function objects computes the average value of some cellset. This cellset only exists on one processor. You can now fool the other processors to do the same operation on a subset of their own cells, and this will avoid a crash.
However, I would like to have the one meaningful value to be available on the other processors, for example for comparison.
I do not know how to do this: make a truly globally accessible variable.

I still hope that Bernard Schaider will fix this, because now my set-up only works for toy problems.

Best,
Duncan

Mehrez April 1, 2016 16:07

Thank you for the quick answer.
I am thinking now to fix this differently but I am not sure if this the best way.
I want to define the variables that I will use in the groovyBC as "storedVariables" in the solver directly (createFileds.H).

Mhrz



Quote:

Originally Posted by Duncan_vdH (Post 592966)
Not completely.
I reformulated the boundary condition in terms of function objects that calculate global
variables. The global variables are than accessed by the groovy boundary condition on the only processor that actually contains that patch.

Now the computation does not crash anymore because it tries to set a boundary condition on a patch that is not available on that processor.

But the global variables are computed on each processor separately and
there is no variable that is truly global for all processors simultaneously.

For example, one function objects computes the average value of some cellset. This cellset only exists on one processor. You can now fool the other processors to do the same operation on a subset of their own cells, and this will avoid a crash.
However, I would like to have the one meaningful value to be available on the other processors, for example for comparison.
I do not know how to do this: make a truly globally accessible variable.

I still hope that Bernard Schaider will fix this, because now my set-up only works for toy problems.

Best,
Duncan


Mehrez May 31, 2016 10:51

Hello again Duncan,
I am still facing this issue.
Defining new variables in the solver seems to be harder (and time consuming) than I thought.
I am trying to explore the path of using global variables but I see that it didn't work well for you.
Did you try to use hierarchical decomposition of your domain and keep the whole boundary (with groovyBC) on the same sub domain and core ? Do you think that doing so will ensure having only one value at the same time for the global variable ?
Thank you in advance.
Mhrz


Quote:

Originally Posted by Duncan_vdH (Post 592966)
Not completely.
I reformulated the boundary condition in terms of function objects that calculate global
variables. The global variables are than accessed by the groovy boundary condition on the only processor that actually contains that patch.

Now the computation does not crash anymore because it tries to set a boundary condition on a patch that is not available on that processor.

But the global variables are computed on each processor separately and
there is no variable that is truly global for all processors simultaneously.

For example, one function objects computes the average value of some cellset. This cellset only exists on one processor. You can now fool the other processors to do the same operation on a subset of their own cells, and this will avoid a crash.
However, I would like to have the one meaningful value to be available on the other processors, for example for comparison.
I do not know how to do this: make a truly globally accessible variable.

I still hope that Bernard Schaider will fix this, because now my set-up only works for toy problems.

Best,
Duncan


Duncan_vdH June 1, 2016 06:38

Dear Mehrez,

No I did not make any progress.
I still hope this matter is addressed by the Swak4Foam team.

Best,
Duncan

Mehrez June 1, 2016 17:03

Dear Duncan,

Do you know if this bug has been reported again ? I saw that it has been fixed (partially) before on previous swak4Foam versions.

Just to update you, it seems that for "globaleVariables", we can only use "type addGlobalVariable".
The type "calculateGlobalVariables" is not working. The latter type offers more flexibility and allows the user to use expressions to define global variables.

The only thing that I found to bypass this issue is the way I decompose my domain. I use hierarchical decomposition type and ensure that the boundary where I have defined my "groovyBC" using "storedVariables" is shared between all the sub meshes.

Please update this thread if you find a cleaner solution.

Mehrez


Quote:

Originally Posted by Duncan_vdH (Post 602820)
Dear Mehrez,

No I did not make any progress.
I still hope this matter is addressed by the Swak4Foam team.

Best,
Duncan



All times are GMT -4. The time now is 15:59.