[pcaron]

Sandeep,

thank you for your quick reply. I modified the standard interDyMFoam from OF1.6-ext adding a field called alpha1Clone in the createFields.H and the following lines in the main file.

        mesh.update();

        alpha1Clone = alpha1; // <- Added
        alpha1Clone.write();  // <- Added

        if (mesh.changing())

You can download the pictures here. The fields are not exactly the same. You will see the difference at times 0.019 and 0.020.

Your comments let me a bit concerned. A few questions arise
1) Is the remapping step of discontinuos fields an issue due to interFoam or the field itself?
2) May I help you to improve the mapping of discontinuos fields?
3) Due to the geometries I have to discretize I can not use orthogonal meshes. Do you know a way to improve interFoam?

Regards

Pablo

[deepsterblue]

Pablo,

1. The issue with remapping is not due to interFoam, but the field itself - discontinuous fields need to be handled carefully. Improper remapping of VOF fields can lead to mass gain / loss.
2. You can surely help, but it's not altogether trivial - you'll need to locally reconstruct the interface in the area prior to re-meshing, map geometrically with some intersection calculations, and re-assign to the new re-meshed cells. You can alternatively scale up/down in some intelligent way as a form of local repair.
3. I'm probably not the best person to consult on VOF methods, but I do believe that a PLIC approach would go a long way in alleviating the non-orthogonal issues (I think).

[estebanbriones]

Dear Sandeep:

I am using OpenFoam 1.6-ext with your dynamicTopoFvMesh, using the solver sixDOFFoam. Thanks you very much for all that great job!

I run many cases of sedimentation of spheres, without problems, and get very good solutions, with one processor.
But i have a problem with more processors (2,3,4,5...), running the case in paralell. The solution have a good convergence at the begining, but the solution start to oscillate after a remeshing, and break the simulation.

I tryed many modifications of my case, for many days, but i can't find the problem.
I actually think that maybe it's a problem of the code. Do you use sixDOFFoam in paralell today?
can you explain me how i have to use paralell in sixDOFFoam?

I need to run simulation in paralell, because today with one processor the simulation takes too much time for the basic cases, and i need to simulate more complex cases right now.

Thank you in advance,

[joegi.geo]

Hi,

I am having an issue that it seems related to a problem previously reported by olivier_au_chili.

Basically, after updating my system to opensuse 12.2 many apps stop working, included OF-1.6-ext. I am using gcc 4.7.1, I updated OF-1.6-ext and dynamicTopoFvMesh to the latest release and I am using mesquite 2.1.2.

So far I haven't run an actual simulation, I am just using moveDynamicMesh. My problem is that OF is crashing after running a few iterations, this is a partial output using debug 1:


Edge Swapping complete.
Topo modifier time: 0.016324 s
Bisections :: Total: 2, Surface: 0
Collapses :: Total: 0, Surface: 0
Swaps :: Total: 8, Surface: 1
*** Mapping is being skipped ***
Mapping time: 2e-05 s

=================
Mesh reOrdering
=================
Mesh Info [n]:
Points: 1838
Edges: 11154
Faces: 17911
Cells: 8594
Internal Edges: 8985
Internal Faces: 16465
=================
Mesh Info [n+1]:
Points: 1840
Edges: 11168
Faces: 17935
Cells: 8606
Internal Edges: 8999
Internal Faces: 16489
=================
Checking index ranges...Done.
Checking face-cell connectivity...Done.
Checking for unused points...Done.
Checking edge-face connectivity...Done.
Checking point-edge connectivity...Done.
Checking edge-points connectivity...Done.
Checking cell-point connectivity...Done.
ReOrdering points...Done.
ReOrdering cells...Done.
ReOrdering faces...Done.
ReOrdering edges...Done.
Reordering time: 0.051737 s
void dynamicTopoFvMesh::mapFields(const mapPolyMesh&): Mapping fv fields.

Segmentation fault



I managed to track down the problem to:

MapGeometricFields<scalar,fvsPatchField,topoMapper ,surfaceMesh>
(fieldMapper);


If I comment out this line moveDynamicMesh works fine.
Any idea what could be the problem?

I dont fell quite comfortable commenting this line as if I understood well, it is related to conservative mapping.


Thanks for your help

jg

[deepsterblue]

Can you post a simple test-case that fails? I'd like to take a look.

[joegi.geo]

Hi,

Well basically all of them. But you can try circCylinder3d, on my system it crash when time = 7.

Let me add that to compile I am using the option -fpermissive with gcc-4.7.1.


jg

[deepsterblue]

Could you try with the Port-2.2.x branch of the github repository? My 1.6-ext installation is kind of a mess at the moment. I ran the circCylinder3d case with OpenFOAM-2.2.x and it seemed to work okay.

[joegi.geo]

Hi,

Well that is the next point in my to do list. I was looking to solve first the problem with 1.6-ext version as I am doing some developing in there.

In anycase, with version 2.2.X I am having problems as well. Basically everything started after I upgraded my system to opensuse 12.2. I am using gcc 4.7.1, mesquite 2.2.0 and following your installation instructions. Everything compiles fine, but when I use moveDynamicsMesh with circCylinder3d tut (or any of my previous cases), I am getting this error


--> FOAM FATAL IO ERROR:
Unknown patchField type angularOscillatingDisplacement for patch type wall

Valid patchField types are :

18
(
calculated
codedFixedValue
cyclic
cyclicAMI
cyclicSlip
empty
fixedNormalSlip
fixedValue
nonuniformTransformCyclic
processor
processorCyclic
slip
symmetryPlane
timeVaryingUniformFixedValue
uniformFixedValue
value
wedge
zeroGradient
)

file: /home/joegi/OpenFOAM/joegi-2.2.x/my_runs/circCylinder3d/constant/dynamicMeshDict.mesquiteOptions.fixedValuePatches. topWall from line 93 to line 101.

From function PointPatchField<Type>::New(const pointPatch&, const Field<Type>&, const dictionary&)
in file /home/joegi/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/pointPatchFieldNew.C at line 144.

FOAM exiting



Any clue?
Btw, All libraries exist.

This is telling me that moveDynamicMesh is not finding the motion libraries. Those libraries are compiled with dynamicTopoFvMesh? are they different from the ones in OF22x?. Because if I add libs ("libfvMotionSolvers.so"); to controlDict the error disappear, but basically nothing happens.

In anycase let me troubleshoot this issue, maybe there is something odd on my installation.


jg

[joegi.geo]

Hi Sandeep,

Ok I erased my previous OF2 installation, installed a few updates and recompiled everything again and now it seems that it is working. The only observation is that I need to add

libs ("libfvMotionSolvers.so")

To the controlDict dictionary.

Btw, I am still interested in fixing the problem with OF16-ext.


Regards,

jg

[deepsterblue]

I'll take a look at my 1.6-ext installation and see if I can figure out what's wrong. Will keep you posted.

[olivier_au_chili]

@ joegi.geo
Hi Jeogi.geo:

Have you a problem with dynamicTopoFvMesh (last version) when you run it in mpi?

I found that there is a problem in dynamicTopoFvMeshCoupled.C initFieldTransfers

// Subset and send surfaceFields to stream
        cInfo.send<surfaceScalarField>(names[5], types[5], stream[pI]);

>

You can see my previous post:
www.cfd-online.com/Forums/openfoam-solving/111926-questions-dynamictopofvmesh-3.html

Regards,

Olivier

[deepsterblue]

Hello folks - I recently pushed a few bug-fixes to the github repository. Could you check now and tell me if the issue is now rectified?

Thanks

[olivier_au_chili]

Dear Sandeep

ok very good news, thank you very much, I followed your work since many days, I test it this weekend,


Regards,

Olivier

[olivier_au_chili]

Dear Sandeep:

I carried out a quick test:

in the file dynamicTopoFvMesh.C
in the dynamicTopoFvMesh::resetMesh()you forget to remove the function

initFieldTransfers
(
fieldTypes,
fieldNames,
sendBuffer,
recvBuffer
);

Regards,

Olivier

[deepsterblue]

Not sure I follow. That function is required.

[olivier_au_chili]

Dear Sandeep:

Oh sorry, I am stupid, I made a mistake:

void dynamicTopoFvMesh::initFieldTransfers() : Initializing subMesh field transfers.
void polyMesh::clearGeom() : clearing geometric data
Deleting object leastSquaresVectors
Deleting object mesquiteMotionSolver
Deleting object mesquiteMotionSolver
void polyMesh::clearAddressing() : clearing topology
[0] [1] 

[0] [1] 
[1] --> FOAM FATAL IO ERROR: 
[1] 
[1] 
[1] file: unknown
[1] 
FOAM parallel run exiting
[1] 

[0] --> FOAM FATAL IO ERROR: 
[0] 
[0] 
[0] file: unknown
[0] 
FOAM parallel run exiting
[0] 
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD 
with errorcode 1.

NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.

Regards,

Olivier

[deepsterblue]

Alright - I took another look at this, and figured out the problem. I've pushed a fix, so it should work now.

[olivier_au_chili]

Dear Sandeep:

Ok thank you, I will test today,

REgards,

Olivier

[joegi.geo]

Hi Sandeep,

I wonder what were the modifications you introduced?.
I just updated my installation and I am running a first case and it seems that it is a way much slower, it is taking a lot time for computing the edge-bisection/collapse, before it was a way much faster.

Regards,

Joel

[deepsterblue]

Joel,

You would need to quantify that - slower in what way? You might want to check if you got the length-scales right.