Dimensions error when coupling multiple solvers

Official adapters and tutorials
, ,
1

Hi there,

I am currently attempting to solve a fluid-structure interaction problem by coupling multiple solvers using preCICE. These solvers include the single-phase flow solver pimpleDyMFoam, the two-phase flow solver olaDyMFlow, and the structural solver CalculiX. However, I have encountered some issues about the differernt dimensions, see below:

Different dimensions for =
     dimensions : [0 1 0 0 0 0 0] = [0 0 -1 0 0 0 0]


    From function bool Foam::dimensionSet::operator=(const Foam::dimensionSet&) const
    in file dimensionSet/dimensionSet.C at line 171.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::dimensionSet::operator=(Foam::dimensionSet const&) const at ??:?
#3  Foam::DimensionedField<Foam::Tensor<double>, Foam::volMesh>::operator=(Foam::DimensionedField<Foam::Tensor<double>, Foam::volMesh> const&) at ??:?
#4  Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>::operator==(Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#5  preciceAdapter::Adapter::readCheckpoint() at ??:?
#6  preciceAdapter::Adapter::execute() at ??:?
#7  Foam::functionObjects::preciceAdapterFunctionObject::execute() at ??:?
#8  Foam::functionObjectList::execute() at ??:?
#9  Foam::Time::run() const at Time.C:?
#10  ? at ??:?
#11  __libc_start_main in "/lib64/libc.so.6"
#12  ? at ??:?
MPT ERROR: Rank 0(g:0) received signal SIGABRT/SIGIOT(6).
        Process ID: 441624, Host: cirrus-login2, Program: /mnt/lustre/indy2lfs/work/ec055/ec055/yhuang94/OpenFOAM/yhuang94-4.x/platforms/linux64GccDPInt32Opt/bin/olaDyMFlow
        MPT Version: HPE MPT 2.25  08/14/21 03:17:46-root

MPT: --------stack traceback-------
MPT: sh: gdb: command not found

MPT: -----stack traceback ends-----
MPT: On host cirrus-login2, Program /mnt/lustre/indy2lfs/work/ec055/ec055/yhuang94/OpenFOAM/yhuang94-4.x/platforms/linux64GccDPInt32Opt/bin/olaDyMFlow, Rank 0, Process 441624: Dumping core on signal SIGABRT/SIGIOT(6) into directory /mnt/lustre/indy2lfs/work/ec055/ec055/yhuang94/sbm/3d/case1

The vesion information can be found here:
OpenFOAM-4.x (pimpleDyMFoam, olaDyMFlow)
CalculiX-2.15
preCICE-2.4.0

The preCICE configure file can be found here:
precice-config.xml (5.1 KB)

I have tried coupling pimpleDyMFoam, pimpleDyMFoam and CalculiX using preCICE, it worked well without any errors. However, when I tried to couple pimpleDyMFoam, olaDyMFlow and CalculiX for another FSI problem, I encountered the issues described above.

By the way, I have read the previous posts related to this issue. However, the turbulence model in my current case is laminar, which is different from the issue discussed in those posts.
https://precice.discourse.group/t/different-dimensions-for-dimensions-issue/535

@Makis I would greatly appreciate any suggestions or ideas you may have on how to resolve this issue!

2

Hi there,

Regarding the issue mentioned above, here is some additional information:

(1) The divergence issue mentioned above appeared during the second iteration process, rather than being present from the beginning;
(2) The generated log file for the calculation is as follows:
solid.log (6.9 KB)
innerFluid.log (8.6 KB)
outerFluid.log (14.3 KB)
precice-Calculix-convergence.log (210 Bytes)

Any comments or suggestions are greatly appreciated!

3

A quick update:

I build the adapter with debug symbols and get following detailed error information:

--> FOAM FATAL ERROR:
Different dimensions for =
     dimensions : [0 2 0 0 0 0 0] = [0 0 -1 0 0 0 0]

    From function bool Foam::dimensionSet::operator=(const Foam::dimensionSet&) const
    in file dimensionSet/dimensionSet.C at line 171.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::dimensionSet::operator=(Foam::dimensionSet const&) const at ??:?
#3  Foam::DimensionedField<Foam::Tensor<double>, Foam::volMesh>::operator=(Foam::DimensionedField<Foam::Tensor<double>, Foam::volMesh> const&) at ??:?
#4  Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh>::operator==(Foam::tmp<Foam::GeometricField<Foam::Tensor<double>, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#5  preciceAdapter::Adapter::readCheckpoint() at /mnt/lustre/indy2lfs~/OpenFOAM/OpenFOAM-4.x/src/OpenFOAM/lnInclude/tmpI.H:232
#6  preciceAdapter::Adapter::execute() at ~/OpenFOAM/openfoam-adapter-OpenFOAM4/Adapter.C:416
#7  Foam::functionObjects::preciceAdapterFunctionObject::execute() at ~/OpenFOAM/openfoam-adapter-OpenFOAM4/preciceAdapterFunctionObject.C:86
#8  Foam::functionObjectList::execute() at ??:?
#9  Foam::Time::run() const at Time.C:?
#10  ? at ??:?
#11  __libc_start_main in "/lib64/libc.so.6"
#12  ? at ??:?
MPT ERROR: Rank 0(g:0) received signal SIGABRT/SIGIOT(6).
        Process ID: 852826, Host: cirrus-login2, Program: /mnt/lustre/indy2lfs/work/ec055/ec055/yhuang94/OpenFOAM/yhuang94-4.x/platforms/linux64GccDPInt32Opt/bin/olaDyMFlow
        MPT Version: HPE MPT 2.25  08/14/21 03:17:46-root

MPT: --------stack traceback-------
MPT: sh: gdb: command not found

MPT: -----stack traceback ends-----

It’s strange that a different dimensional error occurred, even though I made no changes to the case.
innerFluid.log (13.1 KB)
outerFluid.log (20.0 KB)
solid.log (6.9 KB)

4

Hi @yhuang,

while this is not related to turbulent models, it is related to reading checkpoints. I assume it is also specific to olaDyMFlow.

The respective issue is still open, and we still have no idea why this happens for turbulent models, but we cannot reproduce it for recent OpenFOAM com versions.

It is also interesting that in the beginning you get:

Different dimensions for =
     dimensions : [0 1 0 0 0 0 0] = [0 0 -1 0 0 0 0]

while in your third post you get:

Different dimensions for =
     dimensions : [0 2 0 0 0 0 0] = [0 0 -1 0 0 0 0]

I would assume that the operator= or the copy constructor of some custom (tensor) field of olaDyMFoam modifies the dimensions. So, every time we call it, we modify the dimensions.

Here is where we set up checkpoints in the adapter: openfoam-adapter/Adapter.C at develop · precice/openfoam-adapter · GitHub

As a first debugging step, I would suggest removing the following lines, to find out which is the exact field type:

    doLocalCode(volSymmTensorField);
    doLocalCode(surfaceTensorField);
    doLocalCode(pointTensorField);

After you find the type, maybe you can find the exact field, and then add only all other fields to the list.

This is an ugly workaround, but it may help you go to the next step. I don’t know what impact it could have to not checkpoint the respective field.

2 Likes
5

Hi @Makis,

Thank you for your detailed instructions and valuable suggestions! I have tested the case as you suggested and found that the error was caused by volTensorField, specifically the grad(U) field.

Your help is much appreciated and has enabled me to move on to the next step.

Best regards.

1 Like
6

Good to hear that, but keep in mind that this is only a workaround, not a solution.

It would be very helpful if you find out why this is happening for the grad(U) field.

7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.