Closed sframba closed 1 year ago
The abstract member function on top says
/**
* @brief import fields from the mesh on the array accessible via the given wrapper.
* @param cellBlockName name of the cell block to copy data from.
* @param meshFieldName name of the field in the meshd
* @param isMaterialField Indicate if we want to import material or regular fields
* @param wrapper Wrapper to access the array
*/
virtual void importFieldsOnArray( string const & cellBlockName, string const & meshFieldName, bool isMaterialField, dataRepository::WrapperBase & wrapper ) const = 0;
So it's a cellBlockName
, but the VTKMeshManager
implementation uses another variable name regionName
.
We should fix this naming discrepancy.
Also here we pass region.getName()
; maybe subRegion.getName()
could be a more precise choice.
EDIT: @XL64 see here I bet it's the last tick box of https://github.com/GEOSX/GEOSX/issues/2209! 😵💫
Describe the bug Field import from vtu files does not work anymore for wave propagation.
To Reproduce Steps to reproduce the behavior: Run an Acoustic wave propagation, using an external vtu file containing an hexahedral mesh and a
mediumVelocity
field (to be imported into GEOSX). In the solver, select,targetRegions="{Region}"
, and then define anElementRegion
named"Region"
withcellBlocks="{hexahedra}"
. The velocity field is everywhere zero.Expected behavior The velocity field is correctly imported.
Platform (please complete the following information):
Additional context Likely due to https://github.com/GEOSX/GEOSX/pull/2212/, which changed the
cellBlockName
comparison in theimportFieldsOnArray
method. The code seems to compare the name of the region itself ("Region"
) with the cell block name ("hexahedra"
), skipping the import of the field when the comparison fails. In fact, changing the name of the region itself tohexahedra
seems to be a workaround