|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002440||OpenFOAM||[All Projects] Bug||public||2017-01-23 11:03||2017-02-21 15:03|
|Status||closed||Resolution||unable to reproduce|
|Platform||GNU/Linux||OS||Other||OS Version||(please specify)|
|Target Version||Fixed in Version|
|Summary||0002440: mpi error when defining a custom vector field name UMean in combination with the call to a functionObject in the controlDict|
|Description||I'm using OpenFoam-2.3.0. So I don't know if it is really relevant.|
I initialize a custom vector field.
// averaged velocity
when I call the function Object in the controlDict this caused a crash of the Mpi after several thousand time steps.
The reason for this is that probably in src/postProcessing/functionObjects/utilities/dsmcFields/dsmcFields.C there is a field with the same name as defined in my custom field.
So something goes wrong with the memory when two fields with the same name exist.
|Tags||No tags attached.|
|You will need to start by upgrading to OpenFOAM-4.x or better still OpenFOAM-dev and see if you can reporduce the problem with standard solvers and functionObjects. If the issues relates to the way in which you have coded you own functionObject it cannot be considered a bug in OpenFOAM and will be treated as user-support.|
@michael2015: A few questions:
1- How many subdomains were used?
2- Exactly how many thousand time steps and which 'deltaT'?
3- Was the case running in parallel with more than one machine?
4- Is "UMean" meant to be read from disk from the current time step folder, namely after the 'dsmcFields' function object does its job?
1) The application run on a 7 million grid which I divided for testing purpose in 8, 16, 32 and 64 subdomains.
2) The solver was a steady solver derived from simpleFoam. deltaT was set to 1 but I think for the steady solver deltaT is not relevant. The application crashed after 700, 1400, 3000 and 5000 time steps (or iterations) for the 8, 16, 32 and 64 processor case, respectively. So I guess it is a memory issue.
3) The application was run on a cluster with 16 processors per node.
4) Umean was present in the 0 folder and read from the disk when createField.H was executed. When does OpenFoam read the controlDict?
Actually the surprising thing is that I don't call the dsmcFiel but the probe function. I made another test with the same solver but not calling any function object in the controtDict and the application run smoothly without crashing.
So I guess because of some reason the UMean field in the dsmcFields is created even if the this specific function object is not called but when there is only one of the available function object called in the controlDict.
Hold on, if 'dsmcFields' was not in your list of function objects in 'controlDict', then it should not interfere.
Can you please provide a test case based on one of OpenFOAM's tutorials, even if it's for OpenFOAM 2.3.0, along with the specific 'UMean' code modification that you did to 'simpleFoam'? Preferably so that the same error occurs.
Because right now most signs point to incorrect usage of either the solver or the function objects... and there is at least one possibility that the problem has to do with remote file access, although it's all just a guess.
|Since nearly a month as passed without more details nor test case, I'm closing this as "unable to reproduce".|
|2017-01-23 11:03||michael2015||New Issue|
|2017-01-23 11:10||henry||Note Added: 0007659|
|2017-01-24 21:37||wyldckat||Note Added: 0007661|
|2017-01-25 09:43||michael2015||Note Added: 0007662|
|2017-01-25 12:22||wyldckat||Note Added: 0007664|
|2017-02-21 15:03||wyldckat||Status||new => closed|
|2017-02-21 15:03||wyldckat||Resolution||open => unable to reproduce|
|2017-02-21 15:03||wyldckat||Note Added: 0007787|