Streamlines and AMI patches

johannesk · April 15, 2015, 06:27

Hi,

I have a rhoSimpleFoam case that uses AMI patches that I need to extract streamlines from (OpenFOAM 2.3.1-262087cdf8db). The case ran fine and has converged. I now want to extract streamlines using execFlowFunctionObjects.

In parallel it fails with this error message:

Quote:

[0] --> FOAM FATAL ERROR:
[0] Particle tracking across AMI patches is only currently supported for cases where the AMI patches reside on a single processor
[0]
[0] From function void Foam::Cloud<ParticleType>::initCloud(const bool)
[0] in file /usr/local/share/OpenFOAM/OpenFOAM-2.3.1/src/lagrangian/basic/lnInclude/Cloud.C at line 59.
[0]
FOAM parallel run aborting

In several tries I always got this error message whether I had applied preservePatches or not in decomposeParDict. So I reconstructed the converged result and called execFlowFunctionObjects on a single processor, which fails with this error message:

Quote:

--> FOAM FATAL ERROR:
Particle lost across cyclicAMI patches ami_0 and ami_1 at position (0.34529617 0.013167192 0.906585)

From function template<class TrackData>void Foam::particle::hitCyclicAMIPatch(const cyclicAMIPolyPatch&, TrackData&, const vector&)
in file /usr/local/share/OpenFOAM/OpenFOAM-2.3.1/src/lagrangian/basic/lnInclude/particleTemplates.C at line 1072.

FOAM aborting

Also the trackLength of the streamlines is setup so they should never actually reach the AMI patches. Checkmesh tells me the mesh is fine.

I've run out of ideas, any suggestions on how I can still extract the streamlines?

johannesk · April 19, 2015, 06:23

Tested the most recent version (3.1.x commit 7445bfe6342), the issue persists.
I had a quick look at the source. It seems like the streamline-particle is lost as it hits the cyclicAMI boundary and no corresponding face on the neighbour patch can be found. I'm not sure how this can even happen on a cyclicAMI patch with the same total area. Maybe someone with more insight in the AMI-logic can comment on this?

For the time being I found a simple workaround:

reconstruct the case (using a script and changeDictionary to convert the patch type from cyclicAMI to patch in boundary and BCs to avoid a known bug with reconstructPar an cyclicAMI.)
setting a fixedValue BC instead of cyclicAMI
run execFlowFunctionObjects with the streamline instructions

This workaround only works for me as I'm not interested in streamlines traversing the cyclicAMI boundary.

jason · August 22, 2015, 10:48

Hi,

I have the same problem when running icoUncoupledKinematicParcelDyMFoam in OF v2.4.0 in Ubuntu 14.04. It crashes when the particles reach the AMI boundary and reports the following:

--> FOAM FATAL ERROR:
Particle lost across cyclicAMI patches AMI1a and AMI1b at position (0.105136 0.184009 0.05)

From function template<class TrackData>void Foam:

article::hitCyclicAMIPatch(const cyclicAMIPolyPatch&, TrackData&, const vector&)
in file /home/openfoam/OpenFOAM/OpenFOAM-2.4.0/src/lagrangian/basic/lnInclude/particleTemplates.C at line 1071.

FOAM aborting

#0 Foam::error:

rintStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 ? at ??:?
#3 ? at ??:?
#4 ? at ??:?
#5 ? at ??:?
#6 ? at ??:?
#7 ? at ??:?
#8 ? at ??:?
#9 ? at ??:?
#10 ? at ??:?
#11 ? at ??:?
#12 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#13 ? at ??:?
Aborted (core dumped)

I noticed a bug report/fix here which says the problem is resolved but it appears not.
http://www.openfoam.org/mantisbt/view.php?id=1694

Attached is a simple case: it is a fan and particles enter at the inlet, I want to see where the particles go after passing the fan. The AMI interface surrounds the fan. Just run blockMesh and icoUncoupledKinematicParcelDyMFoam in OF v2.4.0 to reproduce.

The solver crashes at Time = 0.0113s. Note that it will not run on more than one processor due to the other solver error message mentioned in first post below which I haven't followed up yet.

Could anyone advise if they have had any success? I need to use OF v2.4.0 but I will compile OF v3.1.x and test and report back. The workaround will not work as I do want to follow the particles through the AMI interface.

Br

Jason

louisgag · September 8, 2015, 10:21

I anyone is interested, I had a similar problem when tracing streamlines across an AMI interface in Paraview: the great majority of my streamlines would break at the interface and the visualization would seem noncontinuous.

The solution I've found is to change the interpolator type from point to cell.

To do this you'll need to enable advanced settings in the streamline's properties panel (the gear icon).

Regards,

-Louis

alexisespinosa · October 20, 2015, 07:50

I tried a first test of AMI with particles and it did not work properly.

1.) Can you tell me if any additional setup is needed for particles to cross an AMI boundary?

Here is what I did in the test:
i) I used the tutorial oscillatingInletACMI2D as a base case, but changed the dynamicFVMesh to staticFvMesh (as this is my first test, I wanted the mesh to be static).

ii) I created a pimpleParcelDyMFoam solver adding the particle tracking capabilities to the pimpleDyMFoam solver.

iii) I did not modify any boundary condition from the original tutorial (except for what I explained in i)). I added particles in both parts of the domain and let them be transported by the flow.

The particles are transported by the fluid using sphereDrag forces without a problem in any of the blocks of mesh. But when particles need to cross from the first block to the second block they stay trapped in the boundary (as hitting a wall).

2.) From what I have read in this thread, you are loosing the particles when crossing. My problem seems different as they are being contained in the first block of the mesh and not crossing. Anyway, have any one succeeded to see particles crossing properly AMI boundaries? What else needs to be done?

Thanks a lot!

Alexis Espinosa
UWA

Chemicalengineer123 · March 24, 2016, 05:13

Alexisespinosa,

How the particles behave at the AMI interface is governed by the localInteraction type specified in your constant/kinematicCloudProperties dict. What have you currently specified for the the AMI patches?

I had this same problem and then solved it by creating a "pass" interaction type as outlined here http://www.openfoam.org/mantisbt/view.php?id=1949 this link gives a very good step by step guide to how you create this interaction type.

Best of luck and let us know if you managed to solve your issue!

April 19, 2015, 06:23	Workaround	#2
johannesk New Member Johannes Kneer Join Date: Mar 2009 Location: Germany, Karlsruhe Posts: 13 Rep Power: 17	Tested the most recent version (3.1.x commit 7445bfe6342), the issue persists. I had a quick look at the source. It seems like the streamline-particle is lost as it hits the cyclicAMI boundary and no corresponding face on the neighbour patch can be found. I'm not sure how this can even happen on a cyclicAMI patch with the same total area. Maybe someone with more insight in the AMI-logic can comment on this? For the time being I found a simple workaround: reconstruct the case (using a script and changeDictionary to convert the patch type from cyclicAMI to patch in boundary and BCs to avoid a known bug with reconstructPar an cyclicAMI.) setting a fixedValue BC instead of cyclicAMI run execFlowFunctionObjects with the streamline instructions This workaround only works for me as I'm not interested in streamlines traversing the cyclicAMI boundary. __________________ -- Johannes Kneer Institute for Thermal Turbomachinery Karlsruhe Institute of Technology Last edited by johannesk; April 19, 2015 at 16:21.

September 8, 2015, 10:21		#4
louisgag Senior Member Louis Gagnon Join Date: Mar 2009 Location: Stuttgart, Germany Posts: 338 Rep Power: 18	I anyone is interested, I had a similar problem when tracing streamlines across an AMI interface in Paraview: the great majority of my streamlines would break at the interface and the visualization would seem noncontinuous. The solution I've found is to change the interpolator type from point to cell. To do this you'll need to enable advanced settings in the streamline's properties panel (the gear icon). Regards, -Louis callmetao, mahtin360, santisis and 1 others like this.

October 20, 2015, 07:50		#5
alexisespinosa New Member Alexis Espinosa Join Date: Aug 2009 Location: Australia Posts: 20 Rep Power: 17	I tried a first test of AMI with particles and it did not work properly. 1.) Can you tell me if any additional setup is needed for particles to cross an AMI boundary? Here is what I did in the test: i) I used the tutorial oscillatingInletACMI2D as a base case, but changed the dynamicFVMesh to staticFvMesh (as this is my first test, I wanted the mesh to be static). ii) I created a pimpleParcelDyMFoam solver adding the particle tracking capabilities to the pimpleDyMFoam solver. iii) I did not modify any boundary condition from the original tutorial (except for what I explained in i)). I added particles in both parts of the domain and let them be transported by the flow. The particles are transported by the fluid using sphereDrag forces without a problem in any of the blocks of mesh. But when particles need to cross from the first block to the second block they stay trapped in the boundary (as hitting a wall). 2.) From what I have read in this thread, you are loosing the particles when crossing. My problem seems different as they are being contained in the first block of the mesh and not crossing. Anyway, have any one succeeded to see particles crossing properly AMI boundaries? What else needs to be done? Thanks a lot! Alexis Espinosa UWA

March 24, 2016, 05:13		#6
Chemicalengineer123 New Member Philip Donnellan Join Date: Mar 2012 Posts: 6 Rep Power: 14	Alexisespinosa, How the particles behave at the AMI interface is governed by the localInteraction type specified in your constant/kinematicCloudProperties dict. What have you currently specified for the the AMI patches? I had this same problem and then solved it by creating a "pass" interaction type as outlined here http://www.openfoam.org/mantisbt/view.php?id=1949 this link gives a very good step by step guide to how you create this interaction type. Best of luck and let us know if you managed to solve your issue!