Migration to CS 3

Questions and remarks about code_saturne usage
Forum rules
Please read the forum usage recommendations before posting.
Luca

Re: Migration to CS 3

Post by Luca »

Regarding the unnatural velocity field looking at the listing I see that I always have 0 iterations for the velocity components...
Attachments
listing.txt
(860 KiB) Downloaded 487 times
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: Migration to CS 3

Post by Yvan Fournier »

Hello,

Actually, you do have iterations for the initial time steps, so It seems your calculation is simply very stable (you could check this with probes).

We have not looked at your other data yet, so I'll keep you informed.

Regards,

Yvan
Luca

Re: Migration to CS 3

Post by Luca »

I tested the same case with Code_Saturne 2.3 and it works. I noticed a thing that might help you in finding the problem but I'm not 100% sure becouse I didn't try to reproduce it.
In the beginning I used the same .xml file generated by CS 3 in CS 2.3 and it gave me the same problems at the inlet and the same unphysical solution. Then I rebuilt the case in CS 2.3 and it worked.

I hope it will help.
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: Migration to CS 3

Post by Yvan Fournier »

Hello,

With any luck, did you keep a copy of both versions of the XML file ? I could try to compare the 2, and see what could explain the difference.

Regards,

Yvan
Luca

Re: Migration to CS 3

Post by Luca »

Dear Yvan,

unfortunately I didn't keep a copy but in the files I attached in the previous post there is a version that doesn't work...if tomorrow I will have time I will try to repete the experiment.

Working with FSI module I encountered a problem that surprisingly I cannot find in the forum: from CS 2.3 on (I'm sure in 2.2.3 there is no problem), it seems to me that there is a problem with implicit fluid structure interaction coupling. In particular, if only one subitaration is performed everything works fine but when more subiterations are performed it rises an error: attempting to allocate already allocated variable icodcl in tridim.f90

I looked into the tridim.f90 surce and I addad a flag to control the allocation and deallocation of the variables. Now it seems to work fine (find attached) but it would be great if you could confirm that this pach is not introducing other problems. All the parts I changed are marked with my name, Luca Patruno.

Thanks for the incredible support.

Luca
Attachments
tridim.f90
(57.94 KiB) Downloaded 443 times
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: Migration to CS 3

Post by Yvan Fournier »

Hello,

Thanks for the patch, I'll check that in on Friday.

Regarding your other issues, I'll be travelling abroad next week, and will be very busy until my return, so I'm not sure I'll have much time to check it before mid-December. Other colleagues might take a look, but they are also busy with other validation cases. So If you have any new detail which could help pinpoint the issue by then, don't hesitate to keep us informed.

We'll probably upload a new 3.0 beta on Friday or next week, so although none of the (minor) fixes since R4215 (the latest beta) seem to match your problem, you may want to check it.

Best regards,

Yvan
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: Migration to CS 3

Post by Yvan Fournier »

Hello,

I looked at your patch for version 2.3, and could do it in a slightly simpler manner (testing the allocated status), but I do not understand how icodcl could already be allocated when sub-iterating in the unmodified case, as it is done outside the loop on sub-iterations.

So I would like to try to reproduce the error, so as to understand it. Actually, I suspect the error may be due to another, more subtle cause (I am thinking memory overwrite here), and this is only a consequence. To see this, running a version compiled in debug-mode (--enable-debug in configure options) would enable bounds-checking for Fortran arrays, and might detect a prior error, and running this under Valgrind would provide even more information)...

Regards,

Yvan
Luca

Re: Migration to CS 3

Post by Luca »

Dear Yvan,

First of all I understood where the pressure waves at the inlet came from and it was my fault! It was the combination of least squares gradient calculation, Neumann 1st order and wrong initialization in the volume (I accidentally initialized to 0.0 and not at the inlet velocity)

Regarding the non physical solution I couldn't isolate the problem but I have some elements that might help you:
1- The problem is present in CS3 only (From CS3 GUI, with the same input file, I lunched CS2.3 and 2 and in the first case it works fine).
3- The problem is present also without turbulence model activated.
4- The problem is present in both steady and unsteady cases
5- I tried different combinations of solvers for pressure and velocities and the problem is always present.
6- Looking at the listing it is sure that there is a problem with the convergence check:
a) The iterations for the velocity components are 0
b) The required tolerance is not respected.


I also have a question: why the residuals on the velocity components are exactly the same for the three components (also in CS2.3)?

Finally, I think there might be something wrong with the initialization of the turbulence parameters at least it the formula to fix k and omega is used. It's not too problematic becouse a steady state initialization is sufficient to wash the wrong initialization away.

Please find attached the listings obtained in the same case with CS3Beta and 2.3. The tolerance was 10e-5 with 1000 max iterations.

Thank you,
Luca
Attachments
listingCS23.txt
(474.53 KiB) Downloaded 478 times
listingCS3Beta.txt
(474.06 KiB) Downloaded 456 times
Last edited by Luca on Fri Dec 07, 2012 12:16 pm, edited 4 times in total.
Yvan Fournier
Posts: 4208
Joined: Mon Feb 20, 2012 3:25 pm

Re: Migration to CS 3

Post by Yvan Fournier »

Hello Luca,

Thanks for the update. I'll try to take a look soon. The same convergence for all velocity components is not surprising if you have "ivelco = 1" (the default since version 2.3, for coupled velocity components), as in that case, all components are solved together.

This would actually be an interesting additional test: in cs_user_parameters.f90, in the usipsu subroutine, find ivelco, set it to 0, and remove the test around it: handling of turbulent wall laws is slighly different (more terms are implicited in the new version, but there might still be bugs), so if this explains the differences you obtain, it would be precious information (and I would pass all the remaining work on this case on to Martin, as he is the one working most on those parts of the code :) )

Regards,

Yvan
Luca

Re: Migration to CS 3

Post by Luca »

Dear Yvan,

I will try to do it as soon as possible. Nevertheless, the tests I made lately are without turbulence model activated...and the problem persists.

Luca
Post Reply