View Issue Details

IDProjectCategoryView StatusLast Update
0001495OpenFOAMBugpublic2017-04-25 14:02
Reportertniemi Assigned Tohenry  
Status resolvedResolutionfixed 
Summary0001495: mapFields breaks boundary conditions with extra field entries
DescriptionIn 2.3.x it seems that if a boundary condition has extra fields, such as inletValue-field in inletOutlet, it will get mapped to uninitialized random values. I have traced the issue through the code and I think that the problem lies in the directFvPatchFieldMapper used in the target boundary construction. The directFvPatchFieldMapper gets created on line 574 in meshToMeshTemplates.C with a value of -1 for each item. When this mapper is then used to create the target boundary, the extra fields will have uninitialized values, because the mapper can't do anything reasonable. The value field of the boundary condition will get interpolated later on with proper values, but the other fields are left to the uninitialized random state.

This issue was not present in 2.1.x, where the mapping code is different. I think in 2.1.x the mapper has reasonable values which are used to map the other fields.

I have attached a simple test case pair (source target) based on the cavity-tutorial, which should demonstrate the issue. Both cases are identical and the only change compared to the cavity tutorial is that the boundary conditions for walls in p are changed to inletOutlet with uniform and non uniform inletValues. Running mapFields -consistent from source to target will create a target boundary conditions with random inletValues. In my test case the resulting inletValues have entries such as

In actual test cases inf and -nan values are ofter produced, which will immediately crash the solver.

Note: If the source target has a unknown boundary type (ie. generic), the extra field will transfer correctly, if they are uniform. Non-uniform fields will be corrupted, as they are mapped with the -1 mapper.
TagsNo tags attached.



2015-01-21 09:27

reporter (40,696 bytes)


2015-02-05 12:20

manager   ~0003692

Resolved by commit 7404b42a762c6d883b7ab9a9079abe41e4714d9e

Issue History

Date Modified Username Field Change
2015-01-21 09:27 tniemi New Issue
2015-01-21 09:27 tniemi File Added:
2015-02-05 12:20 henry Note Added: 0003692
2015-02-05 12:20 henry Status new => resolved
2015-02-05 12:20 henry Resolution open => fixed
2015-02-05 12:20 henry Assigned To => henry