2018-05-25 10:00 BST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002440OpenFOAM[All Projects] Bugpublic2017-02-21 15:03
Assigned To 
StatusclosedResolutionunable to reproduce 
PlatformGNU/LinuxOSOtherOS Version(please specify)
Product Version 
Target VersionFixed in Version 
Summary0002440: mpi error when defining a custom vector field name UMean in combination with the call to a functionObject in the controlDict
DescriptionI'm using OpenFoam-2.3.0. So I don't know if it is really relevant.

I initialize a custom vector field.

    // averaged velocity
    volVectorField UMean

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.
TagsNo tags attached.
Attached Files




henry (manager)

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.


wyldckat (updater)

@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?


michael2015 (reporter)


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.


wyldckat (updater)

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.


wyldckat (updater)

Since nearly a month as passed without more details nor test case, I'm closing this as "unable to reproduce".

-Issue History
Date Modified Username Field Change
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
+Issue History