Duplicate entry in runtime selection table - running MRF case

[albisb]

Hi all,

I am trying to run an MRF simulation in DAFoam and I get the following error:
.....................................................................................................
Create mesh for time = 0
Initializing mesh and runtime for DASolver
DAOpton initialized
Duplicate entry ac in runtime selection table MeshedSurface
#0 /home/dafoamuser/dafoam/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam5error14safePrintStackERSo+0x49) [0x7fe5acacfe99]
#1 /home/dafoamuser/dafoam/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libsurfMesh.so(_ZN4Foam13MeshedSurfaceINS_4faceEE34addfileExtensionConstructorToTableINS_11fileFormats17AC3DsurfaceFormatIS1_EEEC2ERKNS_4wordE+0x100) [0x7fe5ac16b6f0]
#2 /home/dafoamuser/dafoam/OpenFOAM/OpenFOAM-v1812/platforms/linux64GccDPInt32Opt/lib/libsurfMeshADR.so(+0x7a46c) [0x7fe5a45a746c]
#3 /lib64/ld-linux-x86-64.so.2(+0x11b9a) [0x7fe6b8726b9a]
[...]
Duplicate entry tri in runtime selection table MeshedSurface
[...]
Duplicate entry labelToPoint in runtime selection table topoSetPointSource
[...]
.....................................................................................................

I have read online similar errors reporting problems of libraries being named the same way, for instance, in different solver versions, so maybe there is a bug between OpenFOAM and DAFoam libraries?

About my case:

• It runs without problems with simpleFoam
• I'm trying to use DASimpleFoam
• I am running in serial, to avoid the issues with MRF as documented in the FAQs
• For now, I am only trying to use runPrimal
• MRFProperties:
  MRF1
  {
  cellZone cellZone1;
  active yes;
  // Fixed patches (by default they 'move' with the MRF zone)
  nonRotatingPatches ();
  origin (0 0 0);
  axis (0 0 1);
  omega constant 314.16; // 3000 rpm
  }

Does anyone know what may be the issue?

Thanks in advance

[albisb]

As an update, I have changed the solver and settings to DATurboFoam, the same solver used for the tutorial of Rotor_37_Compressor and the simulation works. However, this is a compressible solver and is not what I am looking for. This makes me think that there may be a bug with the DASimpleFoam solver and MRF regions. I have seen that a file called runTests_DASimpleFoamMRF.py exists in dafoam/tests/ but I cannot run it to compare settings since the test case is missing

[friedenhe]

Not sure what caused the issue. But you can use runTests_DASimpleFoamMRF.py as a template to test your case. The test file can be downloaded using this command:

dafoam/tests/Allrun

Line 13 in a42fe6c

wget https://github.com/dafoam/files/releases/download/v1.0.0/input.tar.gz --no-check-certificate

[albisb]

Hi, after comparing for a while the case you provided and testing different things, I found that the problem laid on the fact that I had defined functions within controlDict to compute e.g. forces or yPlus. After removing them, everything ran. This is also the reason why DATurboFoam had worked, since I had simply copied the controlDict from the tutorial case. I understand that these functions (at least not all of them) may not be defined in reverse mode and hence the case crashes