[kjmaki]

Hi Niels,

Any plans to extend waves2Foam to version 2.3? I just downloaded waves2fFoam from the svn, and to compile I had to comment out the coordinateRotation in rawVelocityProbes.C, and then I modified the 2.3.x version of interFoam to match waves2Foam, but there appears to be an issue with the alpha1 to alpha.water transition.

Thanks for any help you can provide!

Kevin

[ngj]

Hi Kevin,

Yes, I am planning on trying to get it running on 2.3., but it is a sparetime project, so I cannot say anything on the time horizon. I am seriously thinking of only supporting the %d.%d versions and not the sub-version, because they are simply released too often with enough modification to make the compilation somewhat troublesome.

Could you kindly elaborate more on the alpha thing. I do not think that I quite caught that one.

Kind regards,

Niels

[kjmaki]

Niels,

Thanks for your reply.

I know that your support of the various versions requires a significant amount of effort.

I have compiled your library for 2.3. Here is a very coarse description of the necessary modifications;

* commented out the cooordinateRotation in src/waves2FoamProcessing/postProcessing/postProcessingWave
s/writeRawData/rawVelocityProbes/rawVelocityProbes.C

* commented out the call to compile in src/waves2FoamPorosity in file src/Allwmake

* search and replace alpha1 with alpha.water in all files in src and in applications/utilities

* search and replace phase1 with water and phase2 with air in all files in applications/utilities

The last two bits have to do with the changing to the multiphase naming convention. See more here: http://www.openfoam.org/version2.3.0/multiphase.php.

Best wishes,

Kevin

[ngj]

Good evening,

@Kevin: Thank you for the summary. It will prove helpful, even though it sounds bad that you had to turn so many things off.
What is your initial experience with the new VOF method? Does it go faster with an equally good accuracy?

Kind regards,

Niels

[kjmaki]

Niels,

The changes are not as many, now that I am looking back on them. I have had my own implicit VOF for a while, and the new one is quite nice. I have not done careful testing yet, but some preliminary cases has shown it to deliver as promised. That is I can run with Courant numbers in the range of 2-30, with no problem. For example, the waveFlume tutorial runs great at a Courant number of 15, which is a speed up of 60.

Onward we march......

Kevin

[ngj]

Wow! You just convinced me to have fun compiling tomorrow - fingers crossed for a rainy day

And a great weekend to you,

Niels

[ngj]

Good morning,

With respect to the sampling issue on moving meshes, which is reported several times in the above, have you tried to substitue the surfaceElevation functionObject with a simple line sampling?

This will help you to narrow down, whether the problem is with the sampling or with the surfaceElevation evaluation.

Kind regards,

Niels

[Phicau]

Originally Posted by kjmaki

Niels,

The changes are not as many, now that I am looking back on them. I have had my own implicit VOF for a while, and the new one is quite nice. I have not done careful testing yet, but some preliminary cases has shown it to deliver as promised. That is I can run with Courant numbers in the range of 2-30, with no problem. For example, the waveFlume tutorial runs great at a Courant number of 15, which is a speed up of 60.

Onward we march......

Kevin

Hi Kevin,

AFAIK this is the maximum Courant that is allowed, can you confirm us that in your simulation the real Co reached such a large value? Remember that dt can also be constrained by 'maxDeltaT' or even by the output interval.

IMHO we should be very careful with this feature, one thing is the underlying numerics, which may allow you to use an infinitely large time step and a very different thing is the physics we are solving. When you are dealing with transient wave simulation most of the times you need a degree of accuracy that can only be achieved by using a Co smaller than 1. See how the damBreak case still uses Co = 1.

Steady-state simulations are a different world (and not usually my field), but it seems to me like this feature was specifically designed for them.

Best regards,

Pablo

[kjmaki]

Hi Pablo,

I certainly agree that the possibility to take a large time step does not mean that it is possible to get an accurate answer using such a large time step.

Yes, the time step did eventually correspond with max Co of 25. There is more damping of the wave downstream as the time step size departs largely from 1.

I have not done heavy testing, but the possibility to march with a max Courant number of 10 or 50 is like a factor 10 or 50 speed up. Frequently near the interface the Courant number is a small fraction of the maximum, especially upstream and away from the body where accuracy in the wave propagation is critical.

Best wishes,

Kevin