CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions

[swak4Foam] groovyBC storedVariables in parallel bugfix 9.6.3?

Register Blogs Community New Posts Updated Threads Search

Like Tree2Likes
  • 1 Post By Duncan_vdH
  • 1 Post By Duncan_vdH

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 9, 2016, 10:49
Default groovyBC storedVariables in parallel bugfix 9.6.3?
  #1
New Member
 
Duncan Roy van der Heul
Join Date: May 2010
Posts: 26
Rep Power: 16
Duncan_vdH is on a distinguished road
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 likes this.
Duncan_vdH is offline   Reply With Quote

Old   April 1, 2016, 13:26
Arrow
  #2
Member
 
Sami
Join Date: Nov 2012
Location: Cap Town, South Africa
Posts: 87
Rep Power: 14
Mehrez is on a distinguished road
Hi,
Did you find a solution ?
I have the same issue.
Mhrz
Mehrez is offline   Reply With Quote

Old   April 1, 2016, 16:47
Default
  #3
New Member
 
Duncan Roy van der Heul
Join Date: May 2010
Posts: 26
Rep Power: 16
Duncan_vdH is on a distinguished road
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 likes this.
Duncan_vdH is offline   Reply With Quote

Old   April 1, 2016, 17:07
Default
  #4
Member
 
Sami
Join Date: Nov 2012
Location: Cap Town, South Africa
Posts: 87
Rep Power: 14
Mehrez is on a distinguished road
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 View Post
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 is offline   Reply With Quote

Old   May 31, 2016, 11:51
Question
  #5
Member
 
Sami
Join Date: Nov 2012
Location: Cap Town, South Africa
Posts: 87
Rep Power: 14
Mehrez is on a distinguished road
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 View Post
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 is offline   Reply With Quote

Old   June 1, 2016, 07:38
Default
  #6
New Member
 
Duncan Roy van der Heul
Join Date: May 2010
Posts: 26
Rep Power: 16
Duncan_vdH is on a distinguished road
Dear Mehrez,

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

Best,
Duncan
Duncan_vdH is offline   Reply With Quote

Old   June 1, 2016, 18:03
Default
  #7
Member
 
Sami
Join Date: Nov 2012
Location: Cap Town, South Africa
Posts: 87
Rep Power: 14
Mehrez is on a distinguished road
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 View Post
Dear Mehrez,

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

Best,
Duncan
Mehrez is offline   Reply With Quote

Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[swak4Foam] Segmentation Fault - groovyBC storedVariables in parallel simulations philippose OpenFOAM Community Contributions 6 November 11, 2016 10:24
Explicitly filtered LES saeedi Main CFD Forum 16 October 14, 2015 12:58
simpleFoam parallel AndrewMortimer OpenFOAM Running, Solving & CFD 12 August 7, 2015 19:45
[swak4Foam] groovyBC variable parallel reduce? startingWithCFD OpenFOAM Community Contributions 2 April 8, 2013 04:36
[swak4Foam] Bug in groovyBC in parallel computation Aleksey_R OpenFOAM Community Contributions 19 September 18, 2012 08:50


All times are GMT -4. The time now is 19:20.