Hello,
Both codes allow for restart/continuation, independently of each other. If you start a calculation which is directly coupled and used restart for both codes, the calculations should stay in sync. But it is quite common to run iterations independently first, both to reach steady state and to test both calculation set-ups independently. I am not sure I understand what you mean by allowing for restart at iteration X: do you mean forcing a (same) given iteration in an automatic manner ? This would require ensuring that both codes save restart data at similar time steps, thus running non-coupled but coupling-aware calculations first.
In any case, for development suggestions, don't hesitate to use the bug-tracker on this site (your account works for both).
It would be relatively easy to modify Code_Saturne's cs_syr3_coupling.c file to add post-processing of the exchange coefficient in addition to the heat flux and wall temperature, but this is deliberately not done by default, and here is why:
The exchange coefficient is computed so as to give the correct flux using the fluid temperature in the cell next to the wall, and the wall temperature, as described in my previous post. If your mesh is refined enough, the cell adjacent to the wall will be wholly contained within the flow's boundary layer, so Tfluid_local will be somewhere between the wall temperature and the "reference" fluid temperature. So to get h_local(Twall-Tfluid_local) = h(Twall-Tref) = flux, h_local will need to be higher than the "true" h (in the usual engineering sense, relative to a mean fluid temperature).
That's why the internal exchange coefficient computed by the code should be considered a numerical artifice, and you must be cautious when interpreting it. We we still probably add it in the near future (see https://code-saturne.info/products/code-saturne/issues/81 ).
In any case, if you activated post-processing of the Code_Saturne faces coupled with SYRTHES (either setting ichrsy=1 in usini1.f90, or activating it directly with the GUI; it is activated by default when you use the GUI), you have an extra EnSight part (which you can isolate in ParaView with "extract block"), or MED mesh if you use MED output, and what I would recommend is just using the ParaView calculator to build a field such that h = flux / (Twall-Tfluid_ref), or h = flux / (Twall-T-inlet), hoping you do not have any division by zero.
Now, to get an averaged heat exchange coefficients from the flow characteristics would require choosing between a "numerical" (local) interpretation, or an "engineering" (relative to a mean temperature) interpretation. Depending on the one you choose, the suggestion for how to do it will be a bit different, so tell us what you prefer.
Quality-wise, note that the choice of turbulent model may lead to quite noticeable differences in the heat flux between the fluid and solid domain (k-omega SST is pretty good for dynamics, but may be quite bad at heat exchange prediction; also, using high or low-reynolds models with an inappropriate mesh will lead to always colorful but imprecise results).
Finally, for the good news, SYRTHES4 uses a 1st order mesh, so you won't have to bother with 2nd order meshes anymore, has a Qt4-based GUI, and is parallel. It is still in a beta stage, and I am not quite sure when it will be released, but I'm hoping for sometime near the end of this year. Coupling with Code_Saturne has been tested quite a bit already, with both codes running on a different number of processors (the scheme is similar, with the parallel mapping/interpolation being distributed over both codes instead of handled by SYRTHES alone).
Best regards,
Yvan
Chaining Aster and Saturne
Forum rules
Please read the forum usage recommendations before posting.
Please read the forum usage recommendations before posting.
-
Claus Andersen
Re: Chaining Aster and Saturne
Okay, I actually think you explained what I meant by 'iteration X': As far as I can tell, SYRTHES can reach steady state with much bigger time steps and fewer iterations than Code_Saturne can reach steady state - which is not surprising.
What I'd like, is to use that fact, to save time on a coupled simulation. In simplified terms, I would like to heat up the pins and reach a steady state with SYRTHES, then 'turn on' the coolant with Code_Saturne.
As it is now (I think), SYRTHES startes 'heating' up the pins at t=0 with the coupled simulation, and at very small increments, effectively wasting processing power that could be used for running Code_Saturne on two CPUs.
I would like to:
*Reach steady state with SYRTHES, with approximated ex. coef (or other?) BC for the shared faces during this phase - (bloody fast at that with dT as convergence criteria)
*Reach steady state with Code_Saturne - let the code ramp up the calculation until the flow settles.
*THEN start the coupling to see how the heat flux affects the fluid etc. etc.
Hmmmmmmmmmm - now that I think of it, while typing this - wouldn't it just be easier to give SYRTHES an "/ Entree des conditions initiales" value of (in this case) 40C...? Run a Code_Saturne sim. until steady state, then use the restart file from that sim., to start the coupled simulation.
Let me know if I've completely misunderstood the whole concept.
I will let a sim. run overnight and see what happens - for some reason the time dependent results from SYRTHES (2ensight) gets garbled and can't be read with Paraview - running with syrthes2ensight geoms.syr resusc1.res nameofcasefile
As for SYRTHES4, great news! I much prefer a GUI over CLI/text for clarity - while retaining complex functionality in user files if they can't be readily incorporated in the GUI. As fast and easy as SYRTHES is today, any improvements would make it blindingly fast.
I see how the exchange coefficient will be tricky. I will have to get back to you on that, so I can give you a proper reply. The thought was to extract the exch. coef. from a coupled sim. and run a more complex stand alone SYRTHES simulation, to identify possible hotspots on a much more refined mesh etc. As I said, I will get back to you on that once I've given it a bit more thought.
Simulation is running, we'll see what comes of it.
Regards,
Claus
pic. from previous post attached, better post processed for comparison with aircooling.
What I'd like, is to use that fact, to save time on a coupled simulation. In simplified terms, I would like to heat up the pins and reach a steady state with SYRTHES, then 'turn on' the coolant with Code_Saturne.
As it is now (I think), SYRTHES startes 'heating' up the pins at t=0 with the coupled simulation, and at very small increments, effectively wasting processing power that could be used for running Code_Saturne on two CPUs.
I would like to:
*Reach steady state with SYRTHES, with approximated ex. coef (or other?) BC for the shared faces during this phase - (bloody fast at that with dT as convergence criteria)
*Reach steady state with Code_Saturne - let the code ramp up the calculation until the flow settles.
*THEN start the coupling to see how the heat flux affects the fluid etc. etc.
Hmmmmmmmmmm - now that I think of it, while typing this - wouldn't it just be easier to give SYRTHES an "/ Entree des conditions initiales" value of (in this case) 40C...? Run a Code_Saturne sim. until steady state, then use the restart file from that sim., to start the coupled simulation.
Let me know if I've completely misunderstood the whole concept.
I will let a sim. run overnight and see what happens - for some reason the time dependent results from SYRTHES (2ensight) gets garbled and can't be read with Paraview - running with syrthes2ensight geoms.syr resusc1.res nameofcasefile
As for SYRTHES4, great news! I much prefer a GUI over CLI/text for clarity - while retaining complex functionality in user files if they can't be readily incorporated in the GUI. As fast and easy as SYRTHES is today, any improvements would make it blindingly fast.
I see how the exchange coefficient will be tricky. I will have to get back to you on that, so I can give you a proper reply. The thought was to extract the exch. coef. from a coupled sim. and run a more complex stand alone SYRTHES simulation, to identify possible hotspots on a much more refined mesh etc. As I said, I will get back to you on that once I've given it a bit more thought.
Simulation is running, we'll see what comes of it.
Regards,
Claus
pic. from previous post attached, better post processed for comparison with aircooling.
- Attachments
-
-
Yvan Fournier
Re: Chaining Aster and Saturne
Hello,
If you have a small enough test case that gets garbled by syrthes2ensight, I could take a look if you post it here (or e-mails it directly to me; I think this Forum has a function to do that, though we rearely use it).
For the restarting schemes, all your suggestions should work; just run the simulaton uncoupled first, and activate the coupling once you have satisfactory initial conditions. Your initial time may be different for both codes, but that is not an issue, as the "absolute" time is only used for logging und user messages (and possibly user subroutines if you want define time-dependent boundary conditions); calculations are always based on "current time step, previous time step", used.
In the coupling scheme I described in a previous post, when starting the coupling, the values from the "previous" time steps used and exchanged are simply the initial conditions, so in the case of a restart at time step n for Code_Saturne, Syrthes's wall temperature at time step n-1 is based on SYRTHES's initial conditions, which can be true initial conditions if SYRTHES has not run yet, or restart values if it has already been run, coupled or not. The same goes for Code_Saturne's fluid temperature which is used to calulate the flux and the exchange coefficient). Basically, each code can use initial or restarted conditions indepently of the other, so you can optimize coupling initialization/convergence however best matches the fluid and solid time scales case you are handling.
Best regards,
Yvan
If you have a small enough test case that gets garbled by syrthes2ensight, I could take a look if you post it here (or e-mails it directly to me; I think this Forum has a function to do that, though we rearely use it).
For the restarting schemes, all your suggestions should work; just run the simulaton uncoupled first, and activate the coupling once you have satisfactory initial conditions. Your initial time may be different for both codes, but that is not an issue, as the "absolute" time is only used for logging und user messages (and possibly user subroutines if you want define time-dependent boundary conditions); calculations are always based on "current time step, previous time step", used.
In the coupling scheme I described in a previous post, when starting the coupling, the values from the "previous" time steps used and exchanged are simply the initial conditions, so in the case of a restart at time step n for Code_Saturne, Syrthes's wall temperature at time step n-1 is based on SYRTHES's initial conditions, which can be true initial conditions if SYRTHES has not run yet, or restart values if it has already been run, coupled or not. The same goes for Code_Saturne's fluid temperature which is used to calulate the flux and the exchange coefficient). Basically, each code can use initial or restarted conditions indepently of the other, so you can optimize coupling initialization/convergence however best matches the fluid and solid time scales case you are handling.
Best regards,
Yvan
-
David Monfort
Re: Chaining Aster and Saturne
Hi Claus,
Let me add another feature of Code_Saturne to Yvan's suggestions.
If you want to run steady simulations and have different time-steps in both codes, you can do it. In this case, do not forget to adapt the time-step for the temperature equation by changing the time-step factor to the correct one (1 is the default) in the graphical interface or usini1.f90 (cdtvar(isca(iscalt(1))) = xx). For example, if the time-step is 0.01s in the fluid and 1. in the solid, you need to set the time-step factor to 100.
Of course, this implies the flow and the temperature are not too correlated, and that you want to reach a steady state. Otherwise, the physical interpretation can prove to difficult :)
David
Let me add another feature of Code_Saturne to Yvan's suggestions.
If you want to run steady simulations and have different time-steps in both codes, you can do it. In this case, do not forget to adapt the time-step for the temperature equation by changing the time-step factor to the correct one (1 is the default) in the graphical interface or usini1.f90 (cdtvar(isca(iscalt(1))) = xx). For example, if the time-step is 0.01s in the fluid and 1. in the solid, you need to set the time-step factor to 100.
Of course, this implies the flow and the temperature are not too correlated, and that you want to reach a steady state. Otherwise, the physical interpretation can prove to difficult :)
David
-
Claus Andersen
Re: Chaining Aster and Saturne
I accidentally ran with different time steps in each code, so I can confirm it works ;) I also successfully used 'restart' files in CS while running a coupled sim. - so no one here was trying to pull my leg :)
I have a question regarding SYRTHES though (While Im still pondering the exchange coef. question): Am I trying to do something impossible here when Im only imposing thermal flux to the SYRTHES mesh and nothing else? SYRTHES has initial temp. for the material, and an exchange coefficient is calculated at the shared boundary of SYR. and Saturne - shouldn't that be all there is needed?
With heat sinks you are often left with heat input [W], the dimensions of the sink surface [m²] and then the temperature of the coolant - be it via natural or forced convection.
I can't get my test heat sink to heat up if I give SYRTHES these initial conditions: Thermal flux [W/m²], initial temp [C] and an exchange coefficient [W/m²K] (or just adiabatic BC) - the heat sink cools off a bit due to convection at 1 sec, even if I impose a flux of 1200 (or similar) W/m² on the 10mmX10mm bottom face.
Does the simulation require a Dirichlet temp. imposed on a boundary? O_o
SYRTHES data file attached.
Now, a clarification: When we talk about heat exchange coef. is that synonymous with 'heat transfer coefficient'? Im getting confused by the English terms: From fluid → solid: Ø= α * A * dt where α is called what? (I know the Danish terms :) ) And from fluid → solid → fluid: Ø=U*A*dt fluid where U is called what?
Thanks and regards,
Claus
I have a question regarding SYRTHES though (While Im still pondering the exchange coef. question): Am I trying to do something impossible here when Im only imposing thermal flux to the SYRTHES mesh and nothing else? SYRTHES has initial temp. for the material, and an exchange coefficient is calculated at the shared boundary of SYR. and Saturne - shouldn't that be all there is needed?
With heat sinks you are often left with heat input [W], the dimensions of the sink surface [m²] and then the temperature of the coolant - be it via natural or forced convection.
I can't get my test heat sink to heat up if I give SYRTHES these initial conditions: Thermal flux [W/m²], initial temp [C] and an exchange coefficient [W/m²K] (or just adiabatic BC) - the heat sink cools off a bit due to convection at 1 sec, even if I impose a flux of 1200 (or similar) W/m² on the 10mmX10mm bottom face.
Does the simulation require a Dirichlet temp. imposed on a boundary? O_o
SYRTHES data file attached.
Now, a clarification: When we talk about heat exchange coef. is that synonymous with 'heat transfer coefficient'? Im getting confused by the English terms: From fluid → solid: Ø= α * A * dt where α is called what? (I know the Danish terms :) ) And from fluid → solid → fluid: Ø=U*A*dt fluid where U is called what?
Thanks and regards,
Claus
- Attachments
-
- syrthes.data.txt
- (3.46 KiB) Downloaded 265 times
-
Yvan Fournier
Re: Chaining Aster and Saturne
Hello,
I do not believe that you need a Dirichlet condition, and heat transfer and heat exchange seem to be the same thing.
If I understand correctly, the syrthes.data file seems to be for an uncoupled run, with an initial temperature of 20 degrees C, a flux of 1200 W/m^2 on surfaces of reference 5 (heat source I suppose), and an exchange coefficient of 8 with an exterior (fluid) temperature on faces with reference 4, which are the faces which can be coupled with Code_Saturne. If I am not mistaken, with an initial temperature of 20 degrees, the heat flux on boundaries of color 4 should be h(Text_Tw) = 8(1-20) = -80 W/m^2, which is much lower than your source, but I imagine surfaces of color 4 are much larger than those of color 5.
Are you sure your boundary conditions are referenced everywhere expected ? I am not quite sure what info appears in the Syrthes log, but if SALOME and the convert2syrthes group to color mapping are not enough for diagnostics, you may use the Code_Saturne preprocessor to check that the mesh faces are "colored" correctly (assuming the original mesh is built with SALOME and exported in MED format). Running:
cs_preprocess -m <my_med_mesh_file> --ensight
will give you an EnSight output you may check with ParaView, with blocks for each group. If for example boundary faces were not connected properly with the mesh, they would appear as isolated faces (which might not be easy to check with SMESH). Otherwise, most checking should be feasible directly under SMESH.
I don' see what else could go wrong, but maybe using 'BILAN FLUX SURFACIQUES 4 5' and 'BILAN FLUX VOLUMIQUES -1' at the end of the SYRTHES log could help get more logging on the thermal fluxes and check for balances.
Best regards,
Yvan
I do not believe that you need a Dirichlet condition, and heat transfer and heat exchange seem to be the same thing.
If I understand correctly, the syrthes.data file seems to be for an uncoupled run, with an initial temperature of 20 degrees C, a flux of 1200 W/m^2 on surfaces of reference 5 (heat source I suppose), and an exchange coefficient of 8 with an exterior (fluid) temperature on faces with reference 4, which are the faces which can be coupled with Code_Saturne. If I am not mistaken, with an initial temperature of 20 degrees, the heat flux on boundaries of color 4 should be h(Text_Tw) = 8(1-20) = -80 W/m^2, which is much lower than your source, but I imagine surfaces of color 4 are much larger than those of color 5.
Are you sure your boundary conditions are referenced everywhere expected ? I am not quite sure what info appears in the Syrthes log, but if SALOME and the convert2syrthes group to color mapping are not enough for diagnostics, you may use the Code_Saturne preprocessor to check that the mesh faces are "colored" correctly (assuming the original mesh is built with SALOME and exported in MED format). Running:
cs_preprocess -m <my_med_mesh_file> --ensight
will give you an EnSight output you may check with ParaView, with blocks for each group. If for example boundary faces were not connected properly with the mesh, they would appear as isolated faces (which might not be easy to check with SMESH). Otherwise, most checking should be feasible directly under SMESH.
I don' see what else could go wrong, but maybe using 'BILAN FLUX SURFACIQUES 4 5' and 'BILAN FLUX VOLUMIQUES -1' at the end of the SYRTHES log could help get more logging on the thermal fluxes and check for balances.
Best regards,
Yvan
-
Claus Andersen
Re: Chaining Aster and Saturne
I *think* I narrowed the problem down to conflicting 'colors'. The bottom surface of the heat sink, the heat source, had two designations: a color for a node group (for Dirichlet temp. as required by SYRTHES) and a color for a face group. The node group wasn't assigned anything in SYRTHES for this test, but removing the node groups in SMESH and re-exporting the mesh, seems to have fixed the lack of heat flux.
Now I can impose a flux on the bottom face and impose an exchange condition on surface of the pins and calculate a temp. gradient. I was just about to lose it last night :) I will try a coupled sim. next.
Regards,
Claus
Now I can impose a flux on the bottom face and impose an exchange condition on surface of the pins and calculate a temp. gradient. I was just about to lose it last night :) I will try a coupled sim. next.
Regards,
Claus
-
Claus Andersen
Re: Chaining Aster and Saturne
As mentioned earlier, I have trouble creating time dependant result files from SYRTHES. I have created a much smaller test case for coupling, and Im attaching the result files from SYRTHES.
'PAS DES SORTIES CHRONO SOLIDE=' is set to 1 and the coupled simulation is carried out in 10 steps of 0.1s, as is the Code_Saturne part.
syrthes2ensight geoms.syr resusc1.res asdf gives this output which cannot be read by Paraview (3.4):
Any ideas? Thank you in advance
Regards,
Claus
'PAS DES SORTIES CHRONO SOLIDE=' is set to 1 and the coupled simulation is carried out in 10 steps of 0.1s, as is the Code_Saturne part.
syrthes2ensight geoms.syr resusc1.res asdf gives this output which cannot be read by Paraview (3.4):
claus@claus-desktop:~/tmp_Saturne/OnePin.CASE1.07151820$ syrthes2ensight geoms.syr resusc1.res asdf =============================================================== SYRTHES2ENSIGHT
===============================================================
I. Rupp
--> nom du fichier geom : asdf.ensight.geom
--> nom du fichier case : asdf.ensight.case
MAILLAGE SYRTHES :
------------------
Dimension 3
Dimension des elements 3
Nombre de noeuds 13867
Nombre d'elements 8339
Nombre de noeuds par element 10
Fin de la lecture des coordonnees des noeuds Syrthes
Fin de la lecture de la connectivite Syrthes
Ecriture des 13867 noeuds au format Ensight
Ecriture des 8339 elements au format Ensight
Nombre de faces de reference 4 = 1938
Nombre de faces de reference 5 = 322
Traitement des resultats
--> nombre de variables par pas de temps = 3
Traitement du pas de temps 1 (0.100000 secondes)
--> lecture de la variable TEMP_SOLIDE (localisation 3)
--> lecture de la variable ************************************************************************ (localisation 0)
--> lecture de la variable ************************************************************************ (localisation 0)
Traitement du pas de temps 0 (20000010000000000000.000000 secondes)
--> lecture de la variable .2000216E+020.2000124E+020.2000071E+020.2000040E+020.2000024E+020.2000014E+02 (localisation 0)
--> lecture de la variable .2199351E+020.2199277E+020.2199196E+020.2199057E+020.2199009E+020.2199126E+02 (localisation 0)
--> lecture de la variable 0.2199511E+020.2199181E+020.2199157E+020.2199285E+020.2199436E+020.2199315E+02 (localisation 0) Traitement du pas de temps 3 (0.300000 secondes) --> lecture de la variable TEMP_SOLIDE (localisation 3)
--> lecture de la variable ************************************************************************ (localisation 0)
--> lecture de la variable ************************************************************************ (localisation 0)
Traitement du pas de temps 0 (20000890000000000000.000000 secondes)
--> lecture de la variable 0.2002144E+020.2001456E+020.2000977E+020.2000652E+020.2000435E+020.2000291E+02 (localisation 0)
--> lecture de la variable 0.2291067E+020.2290927E+020.2290779E+020.2290572E+020.2290418E+020.2290420E+02 (localisation 0)
--> lecture de la variable 0.2290681E+020.2290510E+020.2290420E+020.2290514E+020.2290649E+020.2290547E+02 (localisation 0)
Traitement du pas de temps 5 (0.500000 secondes)
--> lecture de la variable TEMP_SOLIDE (localisation 3)
--> lecture de la variable ************************************************************************ (localisation 0)
--> lecture de la variable ************************************************************************ (localisation 0)
Traitement du pas de temps 0 (20005950000000000000.000000 secondes)
--> lecture de la variable 0.2006756E+020.2004949E+020.2003590E+020.2002597E+020.2001879E+020.2001368E+02 (localisation 0) --> lecture de la variable 0.2359901E+020.2359716E+020.2359583E+020.2359349E+020.2359155E+020.2359126E+02 (localisation 0) --> lecture de la variable 0.2359297E+020.2359173E+020.2359083E+020.2359163E+020.2359290E+020.2359201E+02 (localisation 0) Traitement du pas de temps 7 (0.700000 secondes)
--> lecture de la variable TEMP_SOLIDE (localisation 3)
--> lecture de la variable ************************************************************************ (localisation 0)
--> lecture de la variable ************************************************************************ (localisation 0)
Traitement du pas de temps 0 (20019600000000000000.000000 secondes)
--> lecture de la variable 0.2014114E+020.2010831E+020.2008255E+020.2006290E+020.2004804E+020.2003706E+02 (localisation 0)
--> lecture de la variable 0.2417339E+020.2417123E+020.2416968E+020.2416716E+020.2416505E+020.2416446E+02 (localisation 0)
--> lecture de la variable 0.2416530E+020.2416424E+020.2416325E+020.2416412E+020.2416546E+020.2416479E+02 (localisation 0)
Traitement du pas de temps 9 (0.900000 secondes)
--> lecture de la variable TEMP_SOLIDE (localisation 3)
--> lecture de la variable ************************************************************************ (localisation 0) --> lecture de la variable ************************************************************************ (localisation 0)
Traitement du pas de temps 0 (20045640000000000000.000000 secondes)
--> lecture de la variable 0.2023888E+020.2018962E+020.2014986E+020.2011860E+020.2009429E+020.2007587E+02 (localisation 0)
--> lecture de la variable 0.2467566E+020.2467324E+020.2467147E+020.2466880E+020.2466658E+020.2466574E+02 (localisation 0)
--> lecture de la variable 0.2466555E+020.2466473E+020.2466364E+020.2466448E+020.2466587E+020.2466544E+02 (localisation 0)
===============================================================
SYRTHES2ENSIGHT Fin du traitement
===============================================================
Any ideas? Thank you in advance
Regards,
Claus
- Attachments
-
- syrthes_resu.7z
- (695.61 KiB) Downloaded 271 times
-
David Monfort
Re: Chaining Aster and Saturne
Hi Claus,
I tried to generate EnSight files with your chronological results, and indeed that doesn't work at all... I'll try to see this issue with the SYRTHES team, but unfortunately I don't think they will be able to do someting during the summer.
In the meantime, you can still convert the result files to the MED format (with the syrthes2med tool) and read them in SALOME (I also tried that and it works).
Sorry for my useless help here...
David
I tried to generate EnSight files with your chronological results, and indeed that doesn't work at all... I'll try to see this issue with the SYRTHES team, but unfortunately I don't think they will be able to do someting during the summer.
In the meantime, you can still convert the result files to the MED format (with the syrthes2med tool) and read them in SALOME (I also tried that and it works).
Sorry for my useless help here...
David
-
Claus Andersen
Re: Chaining Aster and Saturne
Thanks for the help in confirming that. When I installed SYRTHES I didn't get the syrthes2med utility installed. The source file syrthes2med.c is present, but manually compiling it with GCC returns errors about wrong references to MED - I would imagine it should be compiled against an older version of MED than Ubuntu 10.04 comes with? I believe Ubuntu 10.04 comes with 2.3.5, but I can't check right now.
Any hints would be appreciated, but fortunately Im more interested in the Code_Saturne results than the SYRTHES results right now:)
Regards,
Claus
Ps. I will try the bug-tracker for a possible Ensight/Paraview/Code_Saturne issue.
Any hints would be appreciated, but fortunately Im more interested in the Code_Saturne results than the SYRTHES results right now:)
Regards,
Claus
Ps. I will try the bug-tracker for a possible Ensight/Paraview/Code_Saturne issue.