I ask about Quality mesh because it is very important in multiphase, in fact, he wrote "after 2 days of running in an 8 core pc, i'm stil at 0.15secs just 0.15 seconds, sounds bad quality mesh.

In my experience run with laminar helps to discard problems in turbulent model.

Hello everyone,

Thanks for your replies! My mesh quality is really smooth now, i've already faced that problem before. I have a question though, as you can see in the attached images, the mesh grading on my case is different from the wigley's. On my mesh is dense only round the ship, while wigleys mesh denses gradually. Is this difference is responsible for the small timestep issue i'm dealing with or it's completely irrelevant?

Is it easy to explain why and how i will test the laminar flow? I'm not really familiar with this.

Right now i'm running 2 cases. One with the controlDict i've posted before (default wigley case) and one with the changes Niels suggested. The first is becoming unstable now (i get some negative prices) but generally until that it was right. The other one is really stable but the drag force is much larger than expected. Of course it's early to say because both of them are still below 1 second.

The timestep on the first case is small [it's running on an 8-core pc for 4 days now and it's still at 0.45 sec]. The other one is running on an 4-core pc and the timestep is quite small, bigger than the first of course, but stable. [about a day to reach 0,035 sec]

Thanks again for your time!
Best regards
Ippokratis

Attachment 7279 Attachment 7280

Edit: I've finally tested the laminar flow, it's going quite better than before [little bigger timestep and the forces are stable]. Although the drag force is bigger than expected but it's early to tell. Another question though, in the courant number section of the user guide, it mentions that the dx is defined from some cell number to the distance. Is this about the cells in the x axis to the distance of the domain i've defined in the blockMeshDict or something else?

Hi Ralph,

In my opinion in forcesCalc.h, the force must be calculated like const volScalarField& p_ = mesh_.lookupObject<volScalarField>("p");, and not using p_rgh, if not you never find the balance.

I hope that it is helping.

Who is coming to the 6th OpenFOAM Workshop (http://www.openfoamworkshop.org)? We have just posted the Technical Program for the workshop.

Dr. S.E. Kim will be giving a talk titled, ""Taming OpenFOAM for Ship Hydrodynamics Applications."

Dr. Kevin Maki will be teaching a class in the Training Sessions titled, "Ship Resistance and Propulsion Simulations with OpenFOAM."

Also, the Ship Hydrodynamics Special Interest Group will be meeting on Thursday 16 June as part of the Workshop.

Hi

I'm a new FOAM user. I'm testing a KRISO hull and when I run InterFoam, I have the following message:
#0 Foam::error::printStack(Foam::Ostream&) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#1 Foam::sigFpe::sigFpeHandler(int) in "/opt/openfoam171/lib/linux64GccDPOpt/libOpenFOAM.so"
#2 in "/lib/libc.so.6"
#3 void Foam::MULES::limiter<Foam::geometricOneField, Foam::zeroField, Foam::zeroField>(Foam::Field<double>&, Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::zeroField const&, Foam::zeroField const&, double, double, int) in "/opt/openfoam171/lib/linux64GccDPOpt/libfiniteVolume.so"
#4 void Foam::MULES::explicitSolve<Foam::geometricOneField , Foam::zeroField, Foam::zeroField>(Foam::geometricOneField const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, Foam::zeroField const&, Foam::zeroField const&, double, double) in "/opt/openfoam171/lib/linux64GccDPOpt/libfiniteVolume.so"
#5 Foam::MULES::explicitSolve(Foam::GeometricField<do uble, Foam::fvPatchField, Foam::volMesh>&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh> const&, Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>&, double, double) in "/opt/openfoam171/lib/linux64GccDPOpt/libfiniteVolume.so"
#6
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/interFoam"
#7 __libc_start_main in "/lib/libc.so.6"
#8
in "/opt/openfoam171/applications/bin/linux64GccDPOpt/interFoam"
Exception en point flottant

Any idea about the problem? It's a meshing problem or rather a problem with the solver?

Vincent

Hello Vincent,

In general pressure can cause interfoam to blow up for cases which involve ships... I'm not sure if that's the cause with your problem (search for "floating point" or something like SIGFPE)
A solution for this is to relaxate the pressure which is done with the adopted interFoam solver called shipFoam. This was developed for OF1.6; with a group of people we're trying to get it to work for OF1.7. Go to the shipHydromechanics group for more info (and maybe join the club? :D)

Cheers,

Ralph

Thanks Ralph for your answer. I download OF 1.6 but when I'm trying to unpack the file, there is an error. So for the moment, I stay with OF1.7, where and how I can install ShipFoam for OF1.7?

Cheers

Vincent

You can find the download link in the ship hydromechanics group (follow the link in my signature). Be aware that the tool isn't working as supposed to be; there are still some bugs in it.

Regards,

Ralph

Dear Eric,

I am happy to say that I'll come to the 6th OpenFOAM Workshop :). I read the Technical Program and it looks really promising!

Regards

Norman

Hi Foamers,

I follow this Thread and swak4Foam at openfoamwiki (http://openfoamwiki.net/index.php/Contrib/swak4Foam) to re-simulate the groovyWaveTank case kindly provided by Eric. While the case run smoothly after changing gamma to alpha1 and pd to p_rgh (reason could be found in this thread), the surface elevation increases gradually to the limit of the tank. I believe the outflow B.C. is not very good but am not sure. Anybody has opinion about this issue? Can you please give me any suggestions to improve the simulation?

Cheers,
Albert

Hi Albert,

InterFoam causes sometimes the same issue with a domain which fills itself or has a leak in it. Probably the BC between the versions are not very compatible. What kind of conditions for p, alpha and U did you use for your case?

Hi Ralph,

Thanks for your reply. I thought interFoam is quite mature, and I am surprised when you point out it has a problem like this. Anyway, I hope the increase of water surface in my case caused by initial variables or B.C. settings, rather than by code.

Please find attached the whole case (including p_rgh, alpha and U, of course), which can be run directly by "blockMesh, setFields, and interFoam" under OF17x, provided groovyBC has already been installed .

Kind regards,
Albert

hello, which tool you use to generate the pictures?

Hi All,

I'm currently trying to run a simple yacht hull at Fn 0.35 using the Wigley setup in the OF 2.0 tutorials and I'm getting the usual parasitic waves in the refined region of the domain.

The mesh is of OK quality (nothing amazing though) with max skew at 2.8 and max orthogonality at 51.6 and average at 12.1. Mesh size about 2.2M cells.

When running without the refinement, I don't get those waves except really close to the hull and I guess this is due to diffusion because of coarse mesh and not mesh quality.

I've been trying different settings playing with Co, nAlphaSubCycles and nAlphaCorr without much success. I also tried different interpolation scheemes without much success neither.

Even with the Wigley case I'm getting those waves when refining the mesh supplied (increasing the box 2 refinement level to 3 instead of 2). I assume the original case is coarse enough so that those waves are not visible but it is not treating them.

Has anyone managed to get some nice results without having to make a beautiful structured mesh? We are currently using FineMarine and with the unstructured mesh from Hexpress having local refinements we are getting real nice results both in terms of pretty pictures and drag data. I wish I could do the same with OF!

Attached are 2 shots of what I'm getting after 3000 iterations with LTSInterFoam.

Regards,

Ben

bouclette,
Looking at your pictures you appear to have a refinement zone that is at the free surface that only covers a portion of your domain. I have noticed this kind of behavior tends to occur in a number of cfd programs due to the change in mesh density. As an experiment it may be worth trying a run with an equal refinement across the whole domain free surface and seeing if that eliminates the problem (ie extending the refinement to the inlet and side of the domain). If you think it is due to reflection you might try extending your domain further aft and applying a coarser mesh there to intentionally dampen out waves.
Regards,
Dave

Hi Dave,

Thanks for your reply.

I have tried with no local refinement around the hull and coarser mesh (237k cells) and it does get rid of those waves away from the boat but I still have some dodgy waves close to the hull, especially at bow wave. I will attach a picture later.

Could it be possible to have reflection even with symmetryPlane? my side walls are symmetryPlane.

I guess my issue is partly due to the mesh since there are some settings that do work very well with a structured mesh and do not work when using an unstructured mesh, even if it is of OK quality, for example the series 60 container ship ( https://documents.epfl.ch/users/l/lo...i-OF2.0.tar.gz ) settings will not run at all with a sHM mesh but work perfectly with a structured one (my residuals and forces blow up after 600iterations, problem coming from a random cell that is not far away from a perfect cube).

I don't know if there is a setting that allows to compensate for the unstructured mesh intrinsic defects... Would setting nNonOrthogonalCorrectors (in in fvSolution) to 1 or 2 help ? I will try that next.

Regards,

Ben

Did you try to solve with interFoam?, i think that it is going to work better or at least you can get more info obseving the courant numbers residuals etc.....

I would avoid using a symmetry plane as your far wall BC since if you think about it physically that is saying you have another boat mirrored on the other side (of course if your wall is sufficiently far enough away it should be fine since the wave pattern is constrained).

The non-ortho corrector will improve the calculation of the fluxes across cell boundaries of non-orthogonal cells which is not a bad thing if you are interested in improving accuracy. I don't think it will help though in addressing this issue.

I have not used the LTS version of interFoam yet so I can't comment on the settings to use with regards to it, but I second the thought of trying a run with interFoam to see if it is specific to your setup with regards to the LTS variant or not. I have only ever seen the artificial waves form at the edges of refinement zones but not nearly as severe as those in your pictures. A higher refinement across the free surface region may help alleviate the issue by at least reducing the amplitude of the waves.

Regards,
Dave

Hi Pablo, Dave,

Attached is a picture of the coarse mesh that is refined on the whole domain at level 2 in sHM.

Solver was interFoam and the time is 6s so waves just start reaching the outlet and the run isn't converged yet.

As you can see, there are those dodgy waves along the hull and in the wake. I have set the nNonOrthogonalCorrectors to 1 and it didn't seem to have improved anything.

I will run the case longer over night and see what happens but on the last iterations, Co mean was at 0.0051 and Co max at 0.35 for a timestep of 0.0045s so it still seems to be going ok.

Will post an update mañana.

Regards,

Ben

Hello

I use LTSInterFoam too. For a fishing vessel, I have resistant results closed to commercial CFD code and analytical results. But the free surface is not really nice (I join some picture).
On the another case (multihull), the free surface is more realistic and results close to another CFD code.
I think the problem is in the meshing. Any idea?

best regard

Vincent