[Raffaele Frontera]

Dear all,

I installed on my Ubuntu OpenFoam-5.x, I tried to run the tutorial DTCHull with the solver InterdyMfoam. Unfortunately crashed , now I am kindly asking you if you already know about this bug in Openfoam or I should make a ticket for Openfoam? If I need to make a ticket describing the bug, do you know where I can take look for the procedure to do that?

Thank you in advance,

Raffaele Frontera

[fertinaz]

I guess it would be best to post your log file here, for us to see how it did crash

[Raffaele Frontera]

Originally Posted by fertinaz

I guess it would be best to post your log file here, for us to see how it did crash

Dear Fertinaz,

thank you for your reply,

in attachment you can find the file log.interDyMFoam, I hope this give you enough info to see the bug, otherwise let me know if you need other files.

Thank you in advance,

Raffaele

[Raffaele Frontera]

log .interDyMFoam.zip

Here in attachment the file.

I also would like to ask you if it is necessary to make a ticket for the develop of OpenFoam, and if yes How can I do that?

Thanks

Raffaele

[Raffaele Frontera]

Hi Fertinaz,

I re uploaded the file, I hope that you can open it now

Thanks,

Raffaele

[einstein_zee]

Originally Posted by Raffaele Frontera

Hi Fertinaz,

I re uploaded the file, I hope that you can open it now

Thanks,

Raffaele

Hi there Raffaele,

I could open your first uploaded log file and as you can see in the last line of your log file it clearly states that you have a Floating Point Exception which can happen due to division by zero. This can happen due to poor boundary conditions set in your problem. Anyways, I could run this simulation till 3.1187s and so far there is no complain from OF while this error happens at 0.37783s in your provided log file! just double-check your case

Hope it helps...

[Raffaele Frontera]

Hi fertinaz,
thank you so much to take look.

It seems strange, because this is just a tutorial that I download from Github (without touching anything, I just made Allrun), so it should work properly.
Can you share your files for the BC?
Can I know with wich version of Openfoam you are running the tutorial and from where did you download it?

thank you in advance,

Raffaele

[fertinaz]

Raffaele

Not all tutorials are very reliable and stable. They provide a basis for your model and usually they require further investigation if the case is complex.

It is hard to say much without looking at the boundary conditions but in my opinion dynamic meshing deteriorates your mesh. Time-steps at early stages are around 1e-04 however they tend to increase up to 1e-03 and your max. Courant number is around 10 just before simulation blows-up.

So I would recommend you to focus on 3 things:

1- I would first run the exact same case without rotating the propellers. Once you are sure with your case setup, you can increase the complexity.

2- Check IC&BCs for your turbulence model. They look like unbounded.

3- If you think OpenFOAM has a bug, you can run the exact same case using an older version of OpenFOAM. 4.1 might be a good for comparison. Then you can debug the solver to figure out what may cause the error.

Hope this helps

[Raffaele Frontera]

Dear Fertinaz,
good morning.

Yes I noticed the changing in the time steps, I agree with you. About your points:

1- I would first run the exact same case without rotating the propellers. Once you are sure with your case setup, you can increase the complexity.

That's what I did, because in this tutorial there is not the propeller yet, only the hull with free trim and free sinkage.

2- Check IC&BCs for your turbulence model. They look like unbounded.

What should I change in particular in the file?

3- If you think OpenFOAM has a bug, you can run the exact same case using an older version of OpenFOAM. 4.1 might be a good for comparison. Then you can debug the solver to figure out what may cause the error.

I runned in Openfoam 4.1 tonight and still crash in a different time step but same fashion.

I think there is something strange that I cannot run for openfoam 4.1 and for openfoam 5.x the DTCHull for InterDyMFoam, so I will make a ticket

Can I ask you, if you can be so kind to share from where you downloaded the tutorial and/or to upload the files here in the forum?

Thank you in advance,

Raffaele

[fertinaz]

Raffaele

Firstly, sorry for the confusion. I thought this case was applying dynamic mesh handling due to the rotating propellers however it does apply it to calculate the forces regarding 6DoF movement. I realised it after I checked the case.

You're right, tutorial fails around 0.37 which is certainly not desired however I don't think that indicates a bug. You can issue a ticket in their bug reporting system (I guess it is bugs.openfoam.org, check google) and see what their opinion is.

However, I made some modifications to the case and it seems to run at the moment.

These are the outputs right before your simulation blows-up:

time step continuity errors : sum local = 604.646, global = -95.6955, cumulative = -95.6955
    Linear velocity: (0 0 5.58537e+06)
    Angular velocity: (0 7.3082e+06 0)

So I assumed that focusing on the solution of pressure eqn may increase the stability. To do that I applied these steps:

• Increased nonOrthogonalCorrectors to 2: Check your mesh quality using checkMesh. If your nonOrthogonality is larger than 70, you might want to use additional iterations to correct the errors occur because of that. There are lots of resources about this issue. You can find them online.
• Increased nCorrectors to 2: See how PIMPLE algorithm works.
• Enabled minIters for U and p_rgh: Since I am not happy with the results of the linear solvers, I want to set a minimum value for number of iterations.
• Disabled turbOnFinalIterOnly: In the log file, omega seems unbounded as well. This option allows to solve turbulence at each iteration.
• Decreased under-relaxation factors: It is set to 1 in the tutorial. I decreased them to 0.3 which of course is not good for accuracy but I want to achieve a stable case that just runs fine at the moment. I want to deal with accuracy later.
• Changed gradSchemes: Using cellMDLimited instead of the default value cellLimited. This is again for stability. It cuts-off gradient computations to avoid too high values. Please read about these to understand their effect.
• Changed laplacianSchemes: Set it to Gauss linear limited 0.5. This is also related to nonOrthogonality and stability. 0.5 denotes a blending factor that imposes nonOrthogonal corrections.

I don't know if these settings will give me the most accurate solution but it definitely provides a stable simulation. If you have experimental results that you can compare that would be great for sure.

By the way, I don't know what exactly you want me to upload. I used the tutorial case when I wrote the technical report you reviewed. It was probably the version OF-2.3 or 2.1 maybe, I am not sure.

Last but not least:

2- Check IC&BCs for your turbulence model. They look like unbounded.

What should I change in particular in the file?

For instance you can start with calculating the initial value of omega. I am not sure if 2 is a very appropriate value.

You can also run a steady state case that converges and take its results and use them as ICs for this specific case.

Good luck!

// Fatih

[Raffaele Frontera]

Dear Fatih,

thank you so much for all your support that you are giving to me, much appreciated.



" You're right, tutorial fails around 0.37 which is certainly not desired however I don't think that indicates a bug. You can issue a ticket in their bug reporting system (I guess it is bugs.openfoam.org, check google) and see what their opinion is.

However, I made some modifications to the case and it seems to run at the moment. "

These are the outputs right before your simulation blows-up:

time step continuity errors : sum local = 604.646, global = -95.6955, cumulative = -95.6955
    Linear velocity: (0 0 5.58537e+06)
    Angular velocity: (0 7.3082e+06 0)

"

I am glad that at least It was not my virtual machine the problem, like at certain point looked like in the ticket that I made for Openfoam, but apparently they closed the issue because they couldn't reproduce the error.
Please, look the following link:

https://bugs.openfoam.org/view.php?id=2868

• Increased nonOrthogonalCorrectors to 2: Check your mesh quality using checkMesh. If your nonOrthogonality is larger than 70, you might want to use additional iterations to correct the errors occur because of that. There are lots of resources about this issue. You can find them online.
• Increased nCorrectors to 2: See how PIMPLE algorithm works.
• Enabled minIters for U and p_rgh: Since I am not happy with the results of the linear solvers, I want to set a minimum value for number of iterations.
• Disabled turbOnFinalIterOnly: In the log file, omega seems unbounded as well. This option allows to solve turbulence at each iteration.
• Decreased under-relaxation factors: It is set to 1 in the tutorial. I decreased them to 0.3 which of course is not good for accuracy but I want to achieve a stable case that just runs fine at the moment. I want to deal with accuracy later.
• Changed gradSchemes: Using cellMDLimited instead of the default value cellLimited. This is again for stability. It cuts-off gradient computations to avoid too high values. Please read about these to understand their effect.
• Changed laplacianSchemes: Set it to Gauss linear limited 0.5. This is also related to nonOrthogonality and stability. 0.5 denotes a blending factor that imposes nonOrthogonal corrections.

About all this kind of options, I didn't find the followings:

minIters for U and p_rgh, where and how should I locate this option in the file U and p_rgh?

under-relaxation factors: In which file is this option?


"I don't know if these settings will give me the most accurate solution but it definitely provides a stable simulation. If you have experimental results that you can compare that would be great for sure."

Did you get stable results?


"Last but not least:

For instance you can start with calculating the initial value of omega. I am not sure if 2 is a very appropriate value.

You can also run a steady state case that converges and take its results and use them as ICs for this specific case. "

Because I am a begineer in OpenFoam, which file I have to change to make a steady state case for my simulation and where I will find the results to use them as ICs? I will find the values for omega, k and nut?
This last part is really important for me because I am trying to set a full scale model for the resistance calculations, and I don't know how to calculated these values to define them in the files k, nut and omega.

If I have a steady state case, the pressure force column in the force.dat file should be zero for all the steps right? the only values that I should have is the Viscous force right?

Again thank you so much for the kind support

Raffaele

P.s. sorry if I didn't quote correctly, I didn't understand how to make it properly

[fertinaz]

Raffaele

Since minIter is an option for linear solvers, it is defined in the fvSolution file. Same as the under-relaxation factors.

Yes, I achieved stability. Simulations ran until the endTime which I set to 10 sec.

If you are a beginner, I strongly suggest you to begin with reading OpenFOAM Users Guide. It is a very good resource and provides information about almost all of the questions you're asking.

[sita]

Hi all,

Thanks a lot for those tips, I managed to get the DTCHull-interDyMFoam tutorial running in OF-5.x (Scientific Linux cluster) with those.

However, I recently upgraded to OF-dev (latest update this week, build: dev-68e9c8eac2bf), and now this tutorial keeps diverging, even after applying all suggested changes.

Things are organised a bit differently in OF-dev: interDyMFoam was merged with interFoam, and the interDyMFoam DTCHull tutorial is now called DTCHullMoving. Apart from that, and the changes that I made to get the OF-5.x version running, nothing changed in this tutorial though, as far as I could see from diff-ing both versions.

When I look at the results I do manage to get before divergence, I see that the forces blow up after a while, the pressure blows up locally at some point on the hull, and the bow is tilted quite far down (see attached images: the green square on the pressure screenshot indicates the only highly skew face in the mesh. The plot shows the viscous force in x-direction).

Does anyone know what's happening here?

Thanks in advance,
Sita

[sita]

Alright, I've got it running now. Turns out that by just using the Allrun script the case runs smoothly. Ahem... should have tried that straight away of course...

What I don't quite get is why the Allrun script calls renumberMesh before decomposePar (normally I run renumberMesh in parallel, after decomposePar, see also this post by Wyldkcat here) and, more importantly, why this makes such a big difference in this case. Can anyone explain?

Thanks!
Sita

[Arghavani]

Hello every one,
I am wondering why in DTCHullwave case the g in constant folder is in minus z-direction but the mUmean in 0 folder in U field is in minus x-direction. could anyone explain about this. Is the DTChull moving in the minus z-direction and wave moving in minus x-direction? actually what we want to observe, moving the wave or moving the DTCHUll?

kind regards,
Arghavan