[arjun]

Originally Posted by akidess

That case is so violent it's difficult to judge by just looking at the video (though I'm sure you had some other quantities to compare to, and I believe you know what you are doing). On your 3cm video (https://www.youtube.com/watch?v=3NRh-uVJ4Ac) there seem to be some similar artifacts close to the walls near the outlet.

Yes you are right, i have been testing it very much. The main reason is this test case, supposed to calculate how much air coming out of outlet. This case does not show that problem, if anything in this case the main problem is that due to too much diffusion from other scheme (other than THINC) some air comes out as numerical error.
This is why earlier it used HRIC and now it is using CICSAM. The testing on it is still going on. I would even work on that dam break case to acertain about what you pointed out.

Acuracy at the moment is quite important specially this 3cm case as the experimental values and numerical errors are in similar values there is not scope for making any errors.

[kal1943335]

Originally Posted by roenby

Just tried to compile the isoAdvector code with OF-2.3.0 simply by renaming the OpenFOAM-2.2.0 directories in isoAdvector/applications and isoAdvector/src to OpenFOAM-2.3.0. The "src" stuff compiles without problems. InterFlow gives an error related to the many API changes introduced in the twoPhaseMixture formulation from OF-2.1.x to 2.2.x on to 2.3.x.

If you want to get an overview of these changes have a look at this file:
https://github.com/OpenFOAM/OpenFOAM...m/Make/options
and the corresponding URL with 2.3.x replaced by 2.2.x and by 2.1.x. Also look at the createFields.H and interFoam.C files and locate the twoPhaseMixture stuff in them to see the difference.

An easier approach would probably be to simply build interFlow-2.3.0 by copying interFoam-2.3.0 and then line by line introduce all the changes you can observe I introduced to get from interFoam-2.2.0 to interFlow-2.2.0.

If you are not in a hurry, I'd advise you to just do something else for a few months and then someone will probably have made a 2.3.0 compatible interFlow version while you were lying on the beach drinking margaritas ;-)

Best,
Johan

Hi Johan,

Thank you very much for your comments. I'll check those files. I wish I could wait for someone else to compile it for 2.3.0, but I'm in a little hurry. I have installed of4.0 version to check and i'm trying to transfer my modifications to your solver.

thank you again for your reply,
Kalpana.

[roenby]

There is an update of the isoAdvector code on github:

Here is an overview of what is changed:

• The basic functionality is unchanged but the code structure and installation process have been streamlined so it should now compile without problems on all newer OpenFOAM releases. It was tested with most versions from 2.2.0 and up to the newest releases 4.1 and v1612+. The Allwmake script makes a copy of the base code in isoAdvector/OpenFOAM into isoAdvector/OpenFOAM-x.y.z and makes necessary API changes before compilation.

• When compiling with an OpenFOAM older than 2.3.0 the case setup of all tutorials in OpenFOAM-x.y.z/run is automatically changed to the older syntax (alpha.water -> alpha1 etc), so they should run out-of-the-box.

• The several solvers that previously existed (interFlow, isoAdvector, mulesFoam, passiveAdvectionFoam) have been collected in one solver, interFlow, which is automatically generated from the interFoam solver of your loaded OpenFOAM installation by the Allwmake script.
  
  To run in interFoam mode using MULES for interface advection the fvSolution.isoAdvector.interfaceMethod should be set to “MULES”.
  
  To run with isoAdvector set interfaceMethod to “isoAdvector”.
  
  To run with HRIC, CICSAM or mHRIC set it to “fvSchemes” and make sure to include e.g. “div(phi,alpha.water) HRIC;” under divSchemes in fvSchemes.
  
  To run a pure advection test where the pressure and velocity field are not solved set fvSolution.isoAdvector.prescribedU to "true".

• The README now includes a description of the different settings in fvSolution.isoAdvector.
  Note that the “clipAlphaTol” setting has been renamed to “snapAlphaTol” which is more descriptive. Similarly “snapAlpha” has been renamed to “clip”.

Kind regards,
Johan

[amachado]

Dear Johan Roenby,

First of all, thanks for your remarkable work and for sharing it with us.

I have made some modifications in interFlow code, in order to consider dynamic mesh. So I have a kind of interDyMFlow. My objective is just to test the code with solid body motion, but the modifications made in the code may enable remeshing and other stuff.

Even though the results with my version of the interDyMFlow seem to be good, the most problem is mass conservation, in this case, volume conservation. The simulated problem was 10 sec, at the end I have this message in the log:

Courant Number mean: 0.0176869 max: 0.0956276
Interface Courant Number mean: 0.00133671 max: 0.056027
deltaT = 9.61181e-05
Time = 10
......
.....
Advection time is 25.6414% of elapsedCpuTime.
Total alpha1 volume: 0.0010103 m3. Deviation from initial: -0.0958426%.

In your tested cases you had better volume preservation. So I think is something related with the dynamic mesh.
Thus, my question is what to do to improve that.

My results can be found here:

https://www.youtube.com/watch?v=f8oIkOsDk50

Originally Posted by roenby

Dear FOAM'ers

During the past almost two years, we have been developing a new concept for sharp interface advection, called IsoAdvector. The scheme has been implemented as a proof-of-concept code in OpenFOAM, and tested with a series of standard advection test cases.

The conclusion so far is that the scheme performs much better than MULES, CICSAM and HRIC both on "pretty" and "ugly" meshes, and also allows maxCo much closer to 1 without significant loss of accuracy.

A paper explaining the new IsoAdvector concept and documenting its performance is submitted to the new journal Royal Society Open Science (RSOS). A preprint is available here:

http://arxiv.org/abs/1601.05392

For some movies, see:
https://www.youtube.com/channel/UCt6...8TTgz1iUX0prAA

Once the RSOS paper is out, the IsoAdvector code will be released as open source at:

https://github.com/isoAdvector (empty at the time of posting)

Naturally, for the scheme to be of practical interest, it must be implemented in an interFoam type solver. This will be the focus of our work in the coming months.

If you have any questions or are interested in collaborating on the testing, further development or application of the code, please do not hesitate to contact me (jro [at] dhigroup dot com).

Best regards,
Johan Roenby

Ps: This work is part of my postdoc project "Breaking the Code of Breaking Waves". For more information about this, please visit: http://roenby.com/postdoc/

[roenby]

Dear Alex

That is awesome! Moving mesh capabilities has been on my todo list for a very long time now. Are you willing to share your modifications?

Regarding the mass conservation, first let me say, loosing 0.1% of volume in 10 secs with 1e-4 sec time steps in my opinion is not that bad and will probably be good enough for many applications. Do you know the corresponding number for you MULES simulation?

That said, isoAdvector is only strictly mass conserving if you run with clip = false and snapAlphaTol = 0. This in turn may lead to build up of unboundedness (probably more likely for larger time steps). I think it might also be the case that if you have very small time steps (which you do with max alphaCo = 0.056027) then the brute force clipping is done many more times per simulation second than if you went with time steps in the range maxAlphaCo = 0.1-0.5.

Another thing to keep in mind is that the p_rghFinal tolerance in fvSolution is also important here since it controls the accuracy with which the volumetric fluxes through the faces of a cell sum to zero as they should in incompressible flow. If this tolerance is loose then the fluxes (phi) that isoAdvector is working with are not conservative and one cannot expect strict conservation from isoAdvector either.

So in summary: First things to try are playing with time step size, clip, snapAlphaTol, p_rghFinal tolerance.

Let us know if any of this works for you.

Kind regards,
Johan

Ps: You could check if the volume conservation problem is caused by the moving mesh by running two versions of the discInUniFlow case: 1) One where the mesh is stationary, 2) One where the mesh moves in some predefined manner. In both these cases the sum of phi's for a cell will be exactly zero as it should (taking the face normal directions properly into account). If they give the same mass conservation accuracy, chances are that it is the phi's calculated in the PISO loop that mess up volume conservation when isoAdvector is coupled with the p-U solver.

[amachado]

Hi Johan,

Sorry for the delay,
I want to share the code. But I would like to know what is the best way to do that, in order to preserve the modifications. github? could we use the same isoAdvector repository?

I have tested interDyMFlow with prescribed U, using the discInUniFlow case, as you said. The deviation from initial alpha volume is -3.5994679952449e-09% after 3 sec. The results were good. Please see the gif attached. For this case, the fvSolution setup was:

isoAdvector
{
interfaceMethod "isoAdvector";
isoFaceTol 1e-8;
surfCellTol 1e-8;
snapAlphaTol 0;
nAlphaBounds 3;
clip false;
prescribedU true;
}

Thus, It seems to me the PISO loop is jeopardizing the volume conservation. There's more research to be done in this part.

PS: I also ran the discInUniFlow case with slow angular velocity (1e-12), and the volume conservation was even better (5.112134860854e-11%).

Thanks,
Alex

prescribedU_interDyMFlow.gif

[amachado]

There is another issue concerning interpolation methods.
I can't run the simulations with the other schemes, (CICSAM, HRIC and interfacevof).
With HRIC I can run but the results don't make sense, it is extremely diffusive.

"I have been seen this message:

--> FOAM Warning :
From function void* Foam::dlOpen(const Foam::fileName&, bool)
in file POSIX.C at line 1037
dlopen error : /home/alex/OpenFOAM/alex-4.1/platforms/linux64GccDPInt32Opt/lib/libVOFInterpolationSchemes.so: undefined symbol: _ZTIN4Foam9UOPstreamE
--> FOAM Warning :
From function bool Foam::dlLibraryTable:pen(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 97
could not load "libVOFInterpolationSchemes.so"

Regards,
Alex

[roenby]

Hi Alex

Sorry for not getting back to you before now. I've been busy with the integration of isoAdvector into OpenFOAM+ which should be released as a new solver in v1706+.

You can follow the development here:
https://develop.openfoam.com/Communi...commits/master

Good to see that your dynamic mesh implementation preserves the volume conservation very well. The shape preservation also looks good until the mesh motion changes direction where there is some distortion in the shape.

Regarding sharing of your dynamiMesh version of isoAdvector, you could fork the isoAdvector project on github, put your modifications/additions into a new branch and make a merge request. If you prefer, you could also send me your code via e-mail and I will try to incorporate it (when I have the time). It is basically up to you. Of course, you will be acknowledged in the README for your contribution.

I don't have time right now to fix the HRIC etc. issue you mention. I've created an issue on github (https://github.com/isoAdvector/isoAdvector/issues/8) and will try to fix it at a later time.

Best regards,
Johan

[Tobi]

Hi all,

just came across the isoAdvector scheme and wonder if you will contribute that scheme to the OpenFOAM toolbox in order to enable it for everybody or lets say - already available in the original source files?

[akidess]

Originally Posted by Tobi

Hi all,

just came across the isoAdvector scheme and wonder if you will contribute that scheme to the OpenFOAM toolbox in order to enable it for everybody or lets say - already available in the original source files?

Which OpenFOAM toolbox? ;-) Considering the contributors most likely candidates would be foam-extend or ESi-OpenFOAM+.

[roenby]

Hi Tobias

Short answer: yes.

Long answer:

I am currently collaborating with ESI-OpenCFD to integrate isoAdvector into OpenFOAM-v1706+ (i.e. openfoam.com). So stay tuned...

There are a number of reasons why I have not felt comfortable contributing the code to the OpenFOAM Foundation (i.e. openfoam.org):

1. The requirement for giving up the copyright of my contribution (or rather DHI's copyright). I am aware of the reasoning behind this requirement. Might consider it if it wasn't for 2. and 3.

2. The almost hostile attitude of the Foundation towards the OpenFOAM community and its contribution.

3. Their reputation of not respecting basic best practices in author acknowledgement (see e.g. [1]).

ESI-OpenCFD have been very helpful and friendly in the code integration process and I believe they are genuinely interested in (and are able and willing to allocate resources for) facilitating a true open source community around their version of OpenFOAM. In my view, this effort has a huge potential for accelerating CFD development with community driven high quality contributions being continuously fed into the code. This is already working in the foam-extend version, but this community suffers to some degree from lack of base funding for code maintenance and community organisation. As I see it, the ideal solution would be a merge of foam-extend and OpenFOAM+ both in terms of code and community.

KR, Johan

[1] Original OpenFOAM author(s)?

[Tobi]

Thanks for your information.

Good to know. However it is an interesting point that you mention. I am working with FOAM for more than 7 years now and I feel very sad about all the different versions and pro's/cons to that. I am always wondering when I join some FOAM User meetings, most of the people are using the Foundation version rather than ESI or Extend, especially based on the fact that these are user meetings I would expect that most of them are using the extend version. However, this is something which everyone has to decide him- or herself. I guess in point #1 there are cons and pros to give the copyrights to the Foundation. I understand it and I have to give my copyright to them too, whenever I put a patch of feature. But if I think about all the actual work that I do in my spare time for the community, which is free accessible, I am not sure if all people are respecting the Copyrights. But this is another story. To your second and third point I cannot say anything about that.

I am always wondering why Henry and Hrv were good friends (Dedicated to ... in their PhD.'s) and now its something complete different. But as I said, I cannot say anything about that only if I would had the chance to talk to Henry and Hrv personally about that topic which will never happen.

All in all, I see that we will not have that contribution to the Foundation version which is understandable. Thanks for the reply (:

[arjun]

Originally Posted by Tobi

Thanks for your information.

Good to know. However it is an interesting point that you mention. I am working with FOAM for more than 7 years now and I feel very sad about all the different versions and pro's/cons to that. I am always wondering when I join some FOAM User meetings, most of the people are using the Foundation version rather than ESI or Extend, especially based on the fact that these are user meetings I would expect that most of them are using the extend version. However, this is something which everyone has to decide him- or herself. I guess in point #1 there are cons and pros to give the copyrights to the Foundation. I understand it and I have to give my copyright to them too, whenever I put a patch of feature. But if I think about all the actual work that I do in my spare time for the community, which is free accessible, I am not sure if all people are respecting the Copyrights. But this is another story. To your second and third point I cannot say anything about that.

I am always wondering why Henry and Hrv were good friends (Dedicated to ... in their PhD.'s) and now its something complete different. But as I said, I cannot say anything about that only if I would had the chance to talk to Henry and Hrv personally about that topic which will never happen.

All in all, I see that we will not have that contribution to the Foundation version which is understandable. Thanks for the reply (:

It seems Henry Weller created FOAM in 1989 and Hrv showed up in imperial college in 1993, so there was three year of development in FOAM before Hrv joined in.

So as far as I am concerned, i am of opinion that Henry Weller is original author of FOAM (because 3 years is significant time).

PS: According to someone who was there when Hrv was doing phd, Hrv was using FOAM for his phd, which seems to be correct way of putting it as in 1996 Hrv dedicates phd to Henry. (does not sound like a equal contribution to me from it).


PS2: I am writing FVUS for last 2 years and it is already a big code with lots of model. Now if i hire some developer to work further, i won't like it if he claims to be the original co-author.

[Ya_Squall2010]

Hello there,

I'd much appreciate if any of you could share with me the status of incorporating the Moving mesh capabilities in isoAdvector. Many thanks!

[kal1943335]

Dear all,
I modified interFlow solver to include dynamic mesh utility (following the steps in interDyMFoam). I managed to compile the solver without errors.
However, I'm getting following warnings and error when I tried damBreakWithObstacle case.

PHP Code:

 Courant Number mean: 0.00115776 max: 0.0353035
Interface Courant Number mean: 2.253e-05 max: 0.0248462
deltaT = 0.00201778
Time = 0.00789334

PIMPLE: iteration 1
Selected 1430 cells for refinement out of 32256.
Refined from 32256 to 42266 cells.
Selected 0 split points out of a possible 1430.
Execution time for mesh.update() = 0.21 s
GAMG:  Solving for pcorr, Initial residual = 1, Final residual = 7.71655e-05, No Iterations 6
GAMG:  Solving for pcorr, Initial residual = 0.0113251, Final residual = 8.2919e-05, No Iterations 2
GAMG:  Solving for pcorr, Initial residual = 0.000616999, Final residual = 4.14787e-05, No Iterations 1
time step continuity errors : sum local = 1.14826e-08, global = -1.81978e-09, cumulative = -1.75e-07
--> FOAM Warning : 
    From function Foam::scalar Foam::isoAdvection::timeIntegratedFlux(...)
    in file isoAdvection/isoAdvection.C at line 535
    Warning: nShifts = 0 on face 61 with pTimes = 4{0.377902} owned by cell 19
--> FOAM Warning : 
    From function Foam::scalar Foam::isoAdvection::timeIntegratedFlux(...)
    in file isoAdvection/isoAdvection.C at line 535
    Warning: nShifts = 0 on face 699 with pTimes = 4{0.339517} owned by cell 192
--> FOAM Warning : 
    From function Foam::scalar Foam::isoAdvection::timeIntegratedFlux(...)
    in file isoAdvection/isoAdvection.C at line 535
    Warning: nShifts = 0 on face 74642 with pTimes = 4{0.556299} owned by cell 23040


--> FOAM FATAL ERROR: 
given label 16843009 greater than the number of geometric faces 132443

    From function Foam::label Foam::polyBoundaryMesh::whichPatch(Foam::label) const
    in file meshes/polyMesh/polyBoundaryMesh/polyBoundaryMesh.C at line 715.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::polyBoundaryMesh::whichPatch(int) const at ??:?
#3  Foam::isoAdvection::timeIntegratedFlux() at ??:?
#4  Foam::isoAdvection::advect() at ??:?
#5  ? at ??:?
#6  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#7  ? at ??:?
Aborted (core dumped) 


I think the problem is isoAdvector surface cells doesn't match once the mesh is refined near the interface. So I have to update the interface location (after the mesh refinement step) before advecting it to the latest time step. However, I have no idea how to do that. Really appreciate if someone can help me with this.

Thank you in advance,
Kalpana

[roenby]

Hi Kalpana

You get an error message from the function Foam:olyBoundaryMesh::whichPatch(int)

saying:

"given label 16843009 greater than the number of geometric faces 132443"

Apparently the fvMesh object which is referenced in the isoAdvector class is not properly updated, when the mesh is update by the function Foam::dynamicRefineFvMesh::update()

Maybe this is related to the fact that the hexRef8 object that the dynamicRefineFvMesh class uses to do the cell cutting works on a polyMesh and not an fvMesh?

I experienced a similar problem and worked around it by moving the consturction of the isoAdvection class from createFields.H to alphaEqn.H. This causes the isoAdvection object to be constructed and destroyed at every time step, which is computationally suboptimal, but works for now.

If you managed to solve this properly, please let me know what you did so we can get it into the isoAdvector code.

Best,
Johan

[kal1943335]

Originally Posted by roenby

Hi Kalpana

You get an error message from the function Foam:olyBoundaryMesh::whichPatch(int)

saying:

"given label 16843009 greater than the number of geometric faces 132443"

Apparently the fvMesh object which is referenced in the isoAdvector class is not properly updated, when the mesh is update by the function Foam::dynamicRefineFvMesh::update()

Maybe this is related to the fact that the hexRef8 object that the dynamicRefineFvMesh class uses to do the cell cutting works on a polyMesh and not an fvMesh?

I experienced a similar problem and worked around it by moving the consturction of the isoAdvection class from createFields.H to alphaEqn.H. This causes the isoAdvection object to be constructed and destroyed at every time step, which is computationally suboptimal, but works for now.

If you managed to solve this properly, please let me know what you did so we can get it into the isoAdvector code.

Best,
Johan

Thank you Johan for your reply,
I gave a quick try on what you suggested. I moved the isoAdvection constructor to .C file. Now I'm not getting that error. However, I'm getting the warning

PHP Code:

--> FOAM Warning : 
    From function Foam::scalar Foam::isoAdvection::timeIntegratedFlux(...)
    in file isoAdvection/isoAdvection.C at line 535
    Warning: nShifts = 0 on face 110271 with pTimes = 4{0} owned by cell 33059 


I'm getting similar warnings in each iterations and seems it's keep increasing. I managed to write few time steps. Then it crashed with the following error.

PHP Code:

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::sigFpe::sigHandler(int) at ??:?
#2  ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3  Foam::isoAdvection::quadAreaCoeffs(Foam::DynamicList<Foam::Vector<double>, 0u, 2u, 1u> const&, Foam::DynamicList<Foam::Vector<double>, 0u, 2u, 1u> const&, double&, double&) at ??:?
#4  Foam::isoAdvection::timeIntegratedArea(Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&, double, double, double) at ??:?
#5  Foam::isoAdvection::timeIntegratedFlux(int, Foam::Vector<double> const&, Foam::Vector<double> const&, double, double, double, double, double) at ??:?
#6  Foam::isoAdvection::timeIntegratedFlux() at ??:?
#7  Foam::isoAdvection::advect() at ??:?
#8  ? at ??:?
#9  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#10  ? at ??:?
Floating point exception (core dumped) 


Can you please explain me about that warning. I'll try it again tomorrow and let you know if I get a good result.

Thank you again,
Kalpana

[roenby]

Hi Kalpana

The isoAdvection construction should not take place in a ".C" file. It should be in the alphaEqn.H file as I wrote. Within the "{}" brackets so it is destroyed properly at each time step.

Also make sure that if your surfCellTol is set to 1e-6 then your p_rghFinal should be lower, e.g. 1e-8 to avoid isoAdvector isocutting cells that are not surface cells but are just cells with bad volume conservation (sum(phi) != 0).

Cheers,
Johan

[kal1943335]

Originally Posted by roenby

Hi Kalpana

The isoAdvection construction should not take place in a ".C" file. It should be in the alphaEqn.H file as I wrote. Within the "{}" brackets so it is destroyed properly at each time step.

Also make sure that if your surfCellTol is set to 1e-6 then your p_rghFinal should be lower, e.g. 1e-8 to avoid isoAdvector isocutting cells that are not surface cells but are just cells with bad volume conservation (sum(phi) != 0).

Cheers,
Johan

Hi Johan,
I have an older version where you used alpha equation inside the .C file. I'll check the latest version.
Thank you again for your suggestions.

Kalpana

[kal1943335]

Hi Johan,
I managed to use the current version of interFlow and combined the modification required to use adaptive mesh refinement. As you suggested I removed the constructor from createFields (createFields/createIsoAdvection.H) and included in alphaEqn.H as follows.

PHP Code:

if (interfaceMethod == "MULES")
{
    #include "alphaEqnMULES.H"
}
else if (interfaceMethod == "isoAdvector")
{
//added from createFields
// Instantiating isoAdvection object for advancing alpha1
isoAdvection advector(alpha1, phi, U);
//done 


in addition to these modifications in the solver, I had to modify the dynamicMeshDict as follows.

PHP Code:

    correctFluxes
    (
        (phi none)
//added
        (phi_0 none)
//done
        (nHatf none)
        (rhoPhi none)
        (alphaPhi none)
        (ghf none)
    ); 


I included my results and comparison with interDyMFoam. other than the slight differences in the interface location, results looks similar. However, I got this warning in some of the time steps

PHP Code:

--> FOAM Warning : 
    From function void Foam::isoCutFace::cutPoints(const pointField&, const scalarField&, Foam::scalar, Foam::DynamicList<Foam::Vector<double> >&)
    in file isoCutFace/isoCutFace.C at line 522
    cutPoints = 3((0.484375 0.046875 0.4375) (0.492188 0.046875 0.4375) (0.5 0.046875 0.4375)) for pts = 5((0.484375 0.046875 0.4375) (0.492188 0.046875 0.4375) (0.5 0.046875 0.4375) (0.5 0.046875 0.421875) (0.484375 0.046875 0.421875)), f - f0 = 5(0 0 0 0.00710071 0.00710071) and f0 = 2.52268e-17 


Really appreciate if you can give me your views on this warning.


Thank you again,
Kalpana