Cloud::storeGlobalPositions has not been called - How to call it?
 

I am trying to implement a coupled Lagrangian-interFoam solver in OF-6 where I want to refine the mesh in two-phase interface region using the dynamicFvRefineMesh option.

However, I encounter the following fatal error as soon as the refinement is done before first timestep.

I tried to add the following lines to my solver loop:
The code compiles but the same problem persists.
The function storeGlobalPositions() is defined in Cloud.H, which is referenced by basicKinematicCollidingCloud.H. If I try to call it like this:
The compiler throws an error that
I am new to the concept of templates so could someone help me understand and formulate the correct way to call the above function? The kinematicCloud object itself is defined like this in createFields.H:


Thanks for taking time to read this.

Interestingly, when I do not call the function at all, keeping my code as:
The code immediately crashes at the very start, when the first refinement is carried out before start of calculations.


However, when I use the kinematicCloud.storeGlobalPositions(); line at the start of time loop, as so:
it runs for the first timestep and crashes after refinement at the start of second timestep, as follows:


Followed by the same error as before, which indicates that the function call does achieve some purpose, except it does not propagate properly through the next step? But why would this be the case, since it is the same loop?


I would really appreciate help on this!! :(

This is a case when foam tells us what to do, but I guess the timing of the call can be a bit ambiguous. Try storing the global positions right before calling mesh.update().

Caelan

Hi Caelan, thanks!
Following from your advice, I made some markers in the solver file to see how solution and function calls progress.

Calling it from within the firstIter() or from outside it, does not make a difference, except getting called every iteration.


From here it seems that the error is generated from within mesh.update(), whereas this was not a problem during the first timestep.

This same storeGlobalPositions function enables the solution to go through the first timestep, wouldn't that mean that it is being read by mesh.update()?

It seems there is some communication gap after kinematicCloud.evolve(). If I do the following, once again the error is thrown from within mesh.update.

Well I am not immediately sure why this is happening, but I just did a quick search for "storeGlobalPositions()" and this solver came up : https://github.com/OpenFOAM/OpenFOAM...icParcelFoam.C. You might try comparing your solver to this one.

Caelan

Thanks for the pointer! An almost exact code is implemented in OF-6 as a separate solver icoUncoupledKinematicParcelDyMFoam which takes the standard solver and adds the lines for storeGlobalPositions, mesh.update and mesh.change. I took that solver and set it up over my domain such that at each timestep, the entire domain gets refined 6000 => 48000 => 380,000 and so on..

Even here, while the first refinement works the solution collapses at the second timestep.


Although it seems to run okay with the tutorial case for this solver, where the mesh is dynamic in the sense that it is moving (not refining).

Have you tried running the tutorial with a dynamic mesh that changes the number of cells? We are quickly approaching the end of my (limited) knowledge of foam LPT, so I'm running out of ideas. Have you tried one of the other types of particle clouds?

Caelan

I haven't tried with other clouds, but I feel the problem would persist because both these functions storeGlobalPositions and autoMap are being inherited from the Cloud class (is that nomenclature correct?)

I did the refinement effect with the tutorial as for my own case. I replaced the moving dynamicMeshDict, with entries for refining. Same as before, I imposed conditions so as to refine the entire mesh, with nothing else happening.
The same error appeared at the end of first refine.


This is how the autoMap function is written, which throws the error.

And the storeGlobalPositions function:
I have a few questions?

Is there some meaningful info we can extract after the second one is executed, so as to see what kind of information is actually getting stored? What sort of query would that be to get some sort of information printed for positions.size() or the globalPositionsPtr_(). That way we may be able to see how things are changing before and after evolve()


Secondly,
what is this argument being passed to autoMap - const mapPolyMesh& mapper? I could not understand how this function is getting called when mesh.update() is called, as there is no reference in the update() function to Cloud.autoMap().






I tried to check validity of globalPositionsPtr_ before mesh.update(), using:

but I am unable to compile it as it declared as private:

hey mrishi,
I had some time to take a look at your issue. I have similar plans as you but I have not started yet so maybe we will have the possibility to have some knowledge exchange concerning this matter.
Regarding your problem, I took a look at the FatalError you are getting in your simulations and it looks like the error is coming from fvMesh::update calling fvMesh::mapFields calling the free function mapClouds, which is then calling the Cloud::autoMap function. From that you can reason that before updating the mesh, the globalPositionPtr_ member in Foam::Cloud has to be set. However in every Cloud::move call (function called during updates of the cloud, the globalPositionPtr_ is cleared, see the documentation: https://www.openfoam.com/documentati...8C_source.html). cloud.storeGlobalPositions() has therefore to be called after every cloud.evolve() (in your code kinematicCloud) for autoMap to function properly. In addition to that and depending on when the first mesh update is performed, the pointer to the global position field will have to be set directly after constructing the cloud (probably in your createClouds.H, looks better this way). I think this can make it work and these are the only assumptions I can make without seeing the part of the code containing the cloud and mesh updating function calls (as one part).
Hope this helps and sorry for not answering all of your questions. Good luck with your task!
RP

Hi Caelan,

I tried the same with a simpler basickinematicCloud instead of my earlier basicKinematicCollidingCloud (which did a lot of back and forth function calling between CollidingCloud and KinematicCloud)and the problem persists.

It seems that this issue will persist for all types deriving from Cloud.H as raumpolizei suggests - Cloud::move function clears globalPositionPtr_ , and following this it seems even when I try to restore it subsequently, it doesn't work properly.




Hi raumpolizei,
Thanks a lot for taking the time. These pointers are very useful.

I too traced the calls, it goes from dynamicFvRefineMesh::update -> dynamicFvRefineMesh::refine -> updateMesh(map) where map is defined after refinement bywhich I take it is a pointer between the old and new meshes (I remember something similar in meshToMesh or mapFields).

This is followed by meshUpdate(map) which I guess you referred as call to mapFields, although I can't locate the definition of this function, so that I could trace it to mapClouds/Cloud::autoMap. Infact nothing turns up with
grep -r "::meshUpdate" in $FOAM_SRC!!

That being said,

indeed the the trail on the cloud side goes from KinematicCloud::evolve -> KinematicCloud::solve -> KinematicCloud::evolveCloud ->KinematicCloud::motion -> Cloud::move (the base class)
where the globalPositionPtr_ gets reset...and then on to postEvolve and return.
I have tried inserting the call to storeGlobalPositions at various points : namely the main code before calling cloud.evolve(),
at the end of cloud::solve(),
at the end of cloud::motion()
but to no avail. :(

OK, this is interesting.

I suppressed the call to Cloud::move (..which resets globalPositionsPtr_). and it turns out that I still get the error. So that eliminates this function as the culprit. This does not surprise me because if this was the source of error, then it would not interfere as I have been calling the storeGlobalPositions once again, just prior to mesh.update.


Two things are important here:
The problem appears from within kinematicCloud.evolve(). - if the call is suppressed, the refinement goes on, PROVIDED that there is a call to kinematicCloud.storeGlobalPositions() before mesh.update()
If the above is not called, then mesh.update fails, even in absence of evolve.


So, storeGlobalPositions() placed before mesh.update() seems to work as intended, while evolve() makes some change which fails the next call to storeGlobalPositions(), wherever that may be placed.



So I believe we need to look at the calls in evolve():



it just calls solve(), where we have :
preEvolve()
evolveCloud()
motion

and
postEvolve()

motion() doesn't really do anything except call move(), so that is harmless as we have established already.





On the other end of possibility we have autoMap unable to register that storeGlobalPositions() was called just before mesh.update().
If I setup my solver such that, I store the GlobalPositions at start of run (outside of runTime loop) and I am able to carry out one mesh.update(). I have specified in my dynamicMeshDict to allow only one level of refinement, which means that the first timestep runs as before, and after cloud.evolve() there is no more immediate call to mesh.update(). As a result the globalPositionPtr_ is not asked for and solution continues for a few timesteps, until when there has been substantial flow in the domain. Now fresh cells become candidates for their one level refinement and once again the error pops up.

Hi All,

I've been following along and agree with what's been said. What is odd is that some native solvers call storeGlobalPositions, so perhaps clearing of the pointer is anticipated and it is supposed to be a fix. However, it must not be functioning as it should -- or the autoMap doesn't register that it has indeed been called. So, I added statements to print globalPositionsPtr_.valid() in the storeGlobalPositions member function, as well as the autoMap function. Here's the output :

.

So we see that it did get reset. Now, let us try adding the code from storeGlobalPositions to the autoMap bit. In the process of recompiling now, so will edit after that finishes with the result.

The previous snippet is the result of adding the code from storeGlobalPositions member function to the autoMap member function. Apparently autoMap is called a few times, but the solver (icoUncoupledKinematicParcelFoam) did make it past the refinement step. While this is certainly not the most efficient solution, it does appear to be working...

Caelan

Hi All,
The method suggested by clapointe does avoid the error!

I'm running it to if the results make sense. But I have some reservations at this point. Here is the output surrounding three refinements (surrounding first two timesteps.)

At the start of first timestep...

....first time step...

..the next timestep..


The functions involved are the same ..evolve which resets, store which restores, and autoMap which reads first, but then doesn't.. (but also does). I am concerned by this strange behaviour, as it could lead to erroneous positions.

I'll update this based on how the solution is evolving, because it seems that the parcel info is not completely lost between the two calls to map.

Things get pretty slow after refining at the interface (6000 -> 1lakh + cells)and I am facing a strange trouble with -parallel: the Courant number suddenly shoots up from 0.01 to 7+ over a single timestep(unrelated to mesh/cloud change). This doesn't happen in serial run. So, as of now working to fix that and waiting on the slowly chugging serial case to see what is happening there.

Hi there! I'm facing the same issue here. Were you finally able to get correct results for the evolution of the particles? To be honest I'm kinda confused about how you solved the problem. Could you please summarize what you did?
Thank you!


Joa

Hey Joa,


Check out the functions storeGlobalPositions and autoMap in Cloud.C.

What clapointe diagnosed and suggested is that these two are not communicating properly.

I used the storeGlobalPositions code as reference and explicitly added the snippet into the autoMap function. This corrected the tracking problem.

It did not fully solve the case though, but that is because when my refined mesh goes back to coarseing somewhere, it leads to problem of some particle getting unindexed. I have not given time to that part of the problem as I am working with some other aspects, but it seems fixable.


cheers!

Hello All,

I am trying to incorporate the dynamic mesh function into my custom solver based on icoReactingMultiphaseInterFoam.

For the Cloud.C file, can someone help me understand how exactly to add the snippet from storeGlobalPositions to the AutoMap function?

Would it be something like this?

template<class ParticleType>
void Foam::Cloud<ParticleType>::autoMap(const mapPolyMesh& mapper)
{

globalPositionsPtr_.reset(new vectorField(this->size())); // added this line (from storeGlobalPositions)

vectorField& positions = globalPositionsPtr_(); // added this line (from storeGlobalPositions)

if (!globalPositionsPtr_.valid())
{
FatalErrorInFunction
<< "Global positions are not available. "
<< "Cloud::storeGlobalPositions has not been called."
<< exit(FatalError);
}

// Ask for the tetBasePtIs to trigger all processors to build
// them, otherwise, if some processors have no particles then
// there is a comms mismatch.
polyMesh_.tetBasePtIs();

const vectorField& positions = globalPositionsPtr_();

label i = 0;
forAllIter(typename Cloud<ParticleType>, *this, iter)
{
positions[i] = iter().position(); // added this line (from storeGlobalPositions)
iter().autoMap(positions[i], mapper);
++ i;
}
}

template<class ParticleType>
void Foam::Cloud<ParticleType>::storeGlobalPositions() const
{
// Store the global positions for later use by autoMap. It would be
// preferable not to need this. If the mapPolyMesh object passed to autoMap
// had a copy of the old mesh then the global positions could be recovered
// within autoMap, and this pre-processing would not be necessary.

// globalPositionsPtr_.reset(new vectorField(this->size())); // commented out

// vectorField& positions = globalPositionsPtr_(); // commented out

//label i = 0; // commented out
//forAllConstIters(*this, iter) // commented out
//{ // commented out
//positions[i] = iter().position(); // commented out
//++i; // commented out
//} // commented out
}

This will compile my solver, but when I run it with a case, OF cannot properly handle the DTRMparticles which relies on Cloud.C so I'm pretty sure that something is not right in the way I combined storeGlobalPositions into AutoMap.

Thanks!

Error when tracking a particle when the containing cell is unrefined
 

Dear Foamers, I have been experiencing a similar issue (tracking error) that happens when the cell containing the particle is unrefined. The error is FOAM FATAL ERROR: (openfoam-2012) Cell not found for particle position (-0.0056421567 -0.081679551 -0.0117107). :

I posted a ticket in OpenFOAM.com but if someone here has experienced something similar, I'd like to know how you dealt with this issue. The ticket is: https://develop.openfoam.com/Develop.../-/issues/1992

Thank you all.