CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions

[isoAdvector] IsoAdvector: A new interface advection scheme for interFoam type calculations

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree65Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   December 16, 2016, 10:09
Default
  #21
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 855
Rep Power: 23
arjun will become famous soon enough
Quote:
Originally Posted by akidess View Post
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.
arjun is offline   Reply With Quote

Old   December 16, 2016, 12:58
Default
  #22
Member
 
Kalpana Hanthanan Arachchilage
Join Date: May 2015
Location: Orlando, Florida, USA
Posts: 30
Rep Power: 7
kal1943335 is on a distinguished road
Quote:
Originally Posted by roenby View Post
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.
kal1943335 is offline   Reply With Quote

Old   January 20, 2017, 05:54
Default IsoAdvector update
  #23
Member
 
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 84
Rep Power: 17
roenby will become famous soon enough
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
Xinze and karlvirgil like this.
roenby is offline   Reply With Quote

Old   May 30, 2017, 12:27
Default
  #24
New Member
 
Alex Machado
Join Date: Feb 2014
Location: Brazil
Posts: 8
Rep Power: 8
amachado is on a distinguished road
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:

Quote:
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



Quote:
Originally Posted by roenby View Post
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/
Dipsomaniac likes this.
amachado is offline   Reply With Quote

Old   May 31, 2017, 06:04
Default
  #25
Member
 
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 84
Rep Power: 17
roenby will become famous soon enough
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.
roenby is offline   Reply With Quote

Old   June 5, 2017, 15:11
Default
  #26
New Member
 
Alex Machado
Join Date: Feb 2014
Location: Brazil
Posts: 8
Rep Power: 8
amachado is on a distinguished road
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:

Quote:
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
Dipsomaniac likes this.
amachado is offline   Reply With Quote

Old   June 7, 2017, 20:52
Default
  #27
New Member
 
Alex Machado
Join Date: Feb 2014
Location: Brazil
Posts: 8
Rep Power: 8
amachado is on a distinguished road
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:

Quote:
--> 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
amachado is offline   Reply With Quote

Old   June 19, 2017, 03:12
Default
  #28
Member
 
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 84
Rep Power: 17
roenby will become famous soon enough
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
roenby is offline   Reply With Quote

Old   June 19, 2017, 10:23
Default
  #29
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,390
Blog Entries: 6
Rep Power: 42
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to 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?
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   June 20, 2017, 01:35
Default
  #30
Senior Member
 
akidess's Avatar
 
Anton Kidess
Join Date: May 2009
Location: Germany
Posts: 1,379
Rep Power: 26
akidess will become famous soon enough
Quote:
Originally Posted by Tobi View Post
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+.
__________________
*On twitter @akidTwit
*Spend as much time formulating your questions as you expect people to spend on their answer.
akidess is offline   Reply With Quote

Old   June 20, 2017, 03:03
Default
  #31
Member
 
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 84
Rep Power: 17
roenby will become famous soon enough
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 and amolrajan like this.
roenby is offline   Reply With Quote

Old   June 20, 2017, 06:10
Default
  #32
Super Moderator
 
Tobi's Avatar
 
Tobias Holzmann
Join Date: Oct 2010
Location: Augsburg
Posts: 2,390
Blog Entries: 6
Rep Power: 42
Tobi has a spectacular aura aboutTobi has a spectacular aura aboutTobi has a spectacular aura about
Send a message via ICQ to Tobi Send a message via Skype™ to 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 (:
__________________
Keep foaming,
Tobias Holzmann
Tobi is offline   Reply With Quote

Old   June 21, 2017, 09:10
Default
  #33
Senior Member
 
Arjun
Join Date: Mar 2009
Location: Nurenberg, Germany
Posts: 855
Rep Power: 23
arjun will become famous soon enough
Quote:
Originally Posted by Tobi View Post
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.
Tobi likes this.
arjun is offline   Reply With Quote

Old   July 5, 2017, 23:35
Default
  #34
Member
 
YS
Join Date: Jan 2010
Posts: 83
Rep Power: 12
Ya_Squall2010 is on a distinguished road
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!
Ya_Squall2010 is offline   Reply With Quote

Old   January 30, 2018, 14:17
Default Adaptive mesh refinement with InterFlow
  #35
Member
 
Kalpana Hanthanan Arachchilage
Join Date: May 2015
Location: Orlando, Florida, USA
Posts: 30
Rep Power: 7
kal1943335 is on a distinguished road
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 mean0.00115776 max0.0353035
Interface Courant Number mean2.253e-05 max0.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 pcorrInitial residual 1, Final residual 7.71655e-05No Iterations 6
GAMG
:  Solving for pcorrInitial residual 0.0113251, Final residual 8.2919e-05No Iterations 2
GAMG
:  Solving for pcorrInitial residual 0.000616999, Final residual 4.14787e-05No Iterations 1
time step continuity errors 
sum local 1.14826e-08, global = -1.81978e-09cumulative = -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.377902owned 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.339517owned 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.556299owned 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
kal1943335 is offline   Reply With Quote

Old   January 30, 2018, 17:40
Default
  #36
Member
 
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 84
Rep Power: 17
roenby will become famous soon enough
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
roenby is offline   Reply With Quote

Old   January 30, 2018, 19:15
Default
  #37
Member
 
Kalpana Hanthanan Arachchilage
Join Date: May 2015
Location: Orlando, Florida, USA
Posts: 30
Rep Power: 7
kal1943335 is on a distinguished road
Quote:
Originally Posted by roenby View Post
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{0owned 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
Attached Images
File Type: jpg Webp.net-gifmaker.jpg (93.8 KB, 31 views)
kal1943335 is offline   Reply With Quote

Old   January 31, 2018, 03:16
Default
  #38
Member
 
Johan Roenby
Join Date: May 2011
Location: Denmark
Posts: 84
Rep Power: 17
roenby will become famous soon enough
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
roenby is offline   Reply With Quote

Old   January 31, 2018, 08:31
Default
  #39
Member
 
Kalpana Hanthanan Arachchilage
Join Date: May 2015
Location: Orlando, Florida, USA
Posts: 30
Rep Power: 7
kal1943335 is on a distinguished road
Quote:
Originally Posted by roenby View Post
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 is offline   Reply With Quote

Old   January 31, 2018, 10:57
Default
  #40
Member
 
Kalpana Hanthanan Arachchilage
Join Date: May 2015
Location: Orlando, Florida, USA
Posts: 30
Rep Power: 7
kal1943335 is on a distinguished road
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(alpha1phiU);
//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::scalarFoam::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)), 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
Attached Images
File Type: jpg InterDyMFlow.jpg (48.6 KB, 30 views)
File Type: jpg interDyMFoam.jpg (48.4 KB, 29 views)
kal1943335 is offline   Reply With Quote

Reply

Tags
interface, interfoam, isoadvector, multiphase, unstructured mesh, vof

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
[Other] simulation of closing the gate using moving mesh simin_ds OpenFOAM Meshing & Mesh Conversion 8 April 12, 2019 05:49
rhoPimpleFoam hardship petrus OpenFOAM Running, Solving & CFD 0 October 7, 2016 02:41
Wrong flow in ratating domain problem Sanyo CFX 17 August 15, 2015 06:20
interFoam/kOmegaSST tank filling with printStackError/Mules simpomann OpenFOAM Running, Solving & CFD 3 February 17, 2014 17:06
T Junction Stability ignacio OpenFOAM Running, Solving & CFD 5 May 2, 2013 10:44


All times are GMT -4. The time now is 12:45.