GitLab

Summary

mapFields (serial application) fails to map from parallelSource to parallelTarget if the fileHandler format is collated. On the other hand the same applications works if the fileHandler is uncollated.

Steps to reproduce

I started from the incompressible/simpleFoam/backwardFacingStep2D with the collated specified in the controlDict and decomposed in 8 subdomain using hierarchical decomposition with n (4 2 1) . I run 30 iterations. ( this is my collatedSourceCase)

I then created a copy of this tutorial and only run the same blockMesh and run the decomposition with collated format. (this my collatedTargetCase).

Then inside the folder of the collatedTargetCase I execute the command : mapFields "path_of_sourceCaseCollated" -mapMethod interpolate -parallelSource -parallelTarget -sourceTime latestTime

I tried with all the available interpolation method but it failed every time in the same way

What is the current bug behaviour?

It fails when It tries to read a block of the targetCollatedCase. Since the mesh between the 2 cases is exactly the same, so are the meshes of the subdomains since the decomposition is deterministic. As you may see from the log below, it mapped correctly the first block but then it fails when it tries to map the second block.

This happens because the original target collated file is overwritten so it loses all the info about the other blocks. So, the the next time the program tries to read the target collated field it cannot find the others blocks.

As a proof I suggest to run the example I mentioned and to have a look at the p field collated file and you will notice that the other blocks are missing.

What is the expected correct behaviour?

The original collated target case should be updated when the write happens at the end of each mapping loop. This means that the blocks should be moved and the number of bytes updated. This is probably the most difficult part.

Relevant logs and/or images

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Source: "/scratch/filippo.giussani/OpenFOAM/openfoam-libraries/run/mapFieldsTest" "sourceCaseCollated" Target: "/scratch/filippo.giussani/OpenFOAM/openfoam-libraries/run/mapFieldsTest" "targetCaseCollated" Mapping method: interpolate

Create databases as time Overriding OptimisationSwitches according to controlDict fileHandler (unregistered) maxThreadFileBufferSize 0;

maxMasterFileBufferSize 2e+09;

Overriding fileHandler to collated I/O : collated [unthreaded] (maxThreadFileBufferSize = 0). Writing may be slow for large file sizes. Overriding OptimisationSwitches according to controlDict fileHandler (unregistered) maxThreadFileBufferSize 0;

maxMasterFileBufferSize 2e+09;

Source processor 0 Overriding OptimisationSwitches according to controlDict fileHandler (unregistered) maxThreadFileBufferSize 0;

maxMasterFileBufferSize 2e+09;

Source time: 30 Target time: 0 mesh size: 2567

Target processor 0 Overriding OptimisationSwitches according to controlDict fileHandler (unregistered) maxThreadFileBufferSize 0;

maxMasterFileBufferSize 2e+09;

mesh size: 2567

Mapping fields for time 30

interpolating p
interpolating nut
interpolating k
interpolating omega
interpolating U

Target processor 1 Overriding OptimisationSwitches according to controlDict fileHandler (unregistered) maxThreadFileBufferSize 0;

maxMasterFileBufferSize 2e+09;

mesh size: 2567

Mapping fields for time 30

interpolating p

--> FOAM FATAL IO ERROR: (openfoam-2112) incorrect first token, expected , found on line 25: error

file: processors8/0/p at line 25.

From Foam::Istream& Foam::List<T>::readList(Foam::Istream&) [with T = char]
in file primitives/chars/lists/charList.C at line 103.

FOAM exiting

Environment information

Providing details of your set-up can help us identify any issues, e.g. OpenFOAM version : v2112 Operating system : centos 8 Compiler : gcc 8.4.0

Possible fixes

adding functionality to the decomposedBlockData class to write multiple times on the collated target field without loosing previous information