Chaining Aster and Saturne

[Claus Andersen]

Is there a REASONABLY uncomplicated way of chaining a thermal analysis from Aster
with Saturne?

I'd like to simulate water or air flowing over a heat sink and experiment with different mass flows etc.

So far I've successfully applied uniform thermal flux (or temperature) to the walls of the domain, and the calculation has reached a steady state.

In Aster I have calculated a temperature field and have a nice gradient.

Now the questions is: is it possible to use the results from Aster (the field from the surface group that the original part and the flow domain shares) as input to Saturne?

When you're explaining it, pretend you're explaining it to someone who doesn't have a Ph.d in fluid dynamics (in fact, don't pretend) :)

I've attached two images to better explain what I mean.

Regards,

Claus

[Claus Andersen]

..and the flow domain

[David Monfort]

Hi Claus,

I would say that there is no straightforward way to transfer data from Code_Aster to Code_Saturne... Code_Aster generally outputs data in MED format and we cannot easily read MED files for boundary conditions definition. Of course, you could try to output information in text files from Code_Aster and then code the reading in the usclim subroutine of Code_Saturne... but I don't know if it is easy to do that in Code_Aster!

An interesting solution(and easier) would be to use SYRTHES for the thermal calculation in the solid, and then have coupled simulations of conjugate heat transfer (better than just chaining for transient flows by the way). Afterwards, you could even transfer the thermal field in the solid to Code_Aster and compute stresses.

Does this helps?

By the way, you could add some prismatic layers next to the shared boundaries in the fluid mesh to get a better gradient calculation, both for the viscous layer and the thermal layer. But of course, meshing will be more difficult ;)

David

[Yvan Fournier]

Hello,

I'll just add that at EDF, the usual workflow for calculations involving CFD and thermal analysis is the one described by David: coupled CFD calculations, with possible transfer of SYRTHES results to Code_Aster for stress analysis. Which means the tools to to this already exist, while simply chaining Code_Aster and Code_Saturne for thermal analysis would require additional development. SYRTHES is much simpler than either Code_Saturne or Code_Aster, and is faster than both (it has less and simpler equations to solve than Code_Saturne, and is much more specialized than Code_Aster).

If you do opt for coupling with SYRTHES, you may need to reconfigure/build/install Code_Saturne, specifying the --with-syrthes=<path> option to the Code_Saturne kernel's configure line (assuming you are using Code_Saturne 2.0-rcx). You may also need the Convert2Syrthes tool to convert from MED to Syrthes formats, which we may send you (the link on the main EDF website has been broken since our PR department changed the site, and we still do not have write access to correct it).

Code_Saturne has a --nsyr option to its "code_saturne create" script for case creation. Once that is done, in the Code_Saturne GUI, the "conjugate heat transfer" page relates to the selection of boundary fluid faces coupled to SYRTHES, and in SYRTHES's syrthes.data input file, a matching list of "colors" or (aka "references") of coupled faces must be defined. That's about all there is to it (except for learning and using SYRTHES in addition to Code_Saturne and Code_Aster).

Best regards,

  Yvan

[Claus Andersen]

Thank you both very much for your answers - I didn't know Aster and Saturne weren't more integrated. The reason I wanted that coupling, is the fact that I have no experience with Syrthes what so ever, but from your posts, Im not so daunted anymore. 

Apart from a good deal of search results about Syrthes/Saturne, are there any simple step by step tutorials like for Saturne, just to get me started?

Since this is first and foremost to satisfy my own curiosity, I'll just start reading up on Syrthes and see where it takes me - you're welcome to attach/send the Convert2syrthes script - the link on the site is indeed broken.

About the mesh, yes it should be refined, still looking for a silver bullet mesher for linux - and impatiently waiting for the Salome that is scheduled for late/end-of-the-year.

Now, lets see how much of it is in French... -_-  :)
 
Edit: seems I can't download Syrthes off the EDF site, the link is broken (I think): http://rd.edf.com/fichiers/fckeditor/File/EDF%20RD/SYRTHES/syrthes3_4_2%285%29.tgz

[Yvan Fournier]

Hello,

Here is an archive of the SYRTHES 3.4.2 sources:

This archive also includes the SYRTHES conversion utilities (in src/ustil). Compared to the full distribution, I simply removed the obsolete conversion to MED 2.2.3 utility (so as to leave only conversion to MED 2.3), and the French documentation, whose link on the main SYRTHES site is not broken (the English documentation PDF is included).

Best regards,

  Yvan

[Claus Andersen]

Thank you for the archive - I have compiled and installed syrthes successfully and recompiled ncs which recognized syrthes during configuration - all in all a thumbs up.

Now all that is left is to plough through the documentation :)
 
Thanks again.
 
Regards,
 
Claus

[Claus Andersen]

A follow-up question regarding time steps: I'm having a little trouble understanding what values to set in SYRTHES. In Code_Saturne I have a stable simulation if the steps are (unsteady calc., uniform steps)  0.001s and 1000 iterations - so that's what I need when I couple CS and SYRTHES.

Now, when coupling the two codes, the number of iterations is decided by SYRTHES ('NOMBRE DE PAS DE TEMPS SOLIDES=' 1000) - having a different number of iterations in CS does not make a difference. Fine, but what value of 'PAS DE TEMPS SOLIDE='   should be set then? 0.001 like in CS?

I might have misunderstood this, but the values in SYRTHES (standalone) is :   "what is the solution after 1 sec, calculated by 1000 steps of 0.001 second."  (which, in this case, seems like overkill for a standalone calculation)

'PAS DE TEMPS SOLIDE=' 0.001
'NOMBRE DE PAS DE TEMPS SOLIDES=' 1000

How does that correlate to CS when a coupling is made?

CS imposes values to the common boundary condition of CS and SYRTHES at each iteration - and what does SYRTHES then do, in terms of time/iterations before it returns a value to the common BC and CS?

Hope I made myself moderately clear :)
 
In return for an answer, a pretty picture of 25C air flowing over 40C pins - BCs for bottom of pins part: Dirichlet 40C, thermal flux of 0.002W/m^2

For some (unknown to me) reason, the calculation becomes unstable about 60% in when exchanging air with water - I will figure that one out soon.
 
Regards,
 
Claus

[Yvan Fournier]

Hello,

Actually, when coupling the 2 codes, the number of iterations is decided by which ever code stops first, so if you set a very high number of iterations for one of the 2, you may control when the calculation stops with the other.

Usually, you should have the same physical time step on both sides, but the codes do not check this, so if the physical phenomena are on very different time scales, using a different time step in each code is a possibility (you just have to remember what you're doing when interpreting the results). If you're looking for a steady solution and are using the steady algorithm or a space-varying time step on the Code_Saturne side, then you really don't need to have the same time step values, but just note the SYRTHES will work just as if it's running an unsteady calculation, so you need enough time steps so that the steady solution may be attained.

As for the numerical coupling scheme, here is what is doe for a given time step n:

- SYRTHES intepolates its wall temerature at coupled nodes to Code_Saturne's coupled faces, and sends that to Code_Saturne

- Code_Saturne receives the SYRTHES wall temperature at time step n-1, and applies this as a Dirichlet boundary condition for temperature

- Code_Saturne sets up its boundary conditions: using the wall temperature provided by Syrthes, the cell-center (i.e. fluid) temperature at time step n-1, and its wall functions (in case of turbulence), it computes the corresponding heat flux, and extracts an exchange coefficient such that the heat flux may be expressed as Flux = h(Twall -Tfluid). The heat flux is used directly by Code_Saturne, and both the exchange coefficient h and the fluid temperature near coupled faces are sent to SYRTHES

- SYRTHES interpolates received h and Tfluid to its own mesh, and uses the (h, Tfluid, Twall) combination as an "exchange coefficient" type boundary condition.

- Each code computes the rest of its time step independently

It seems that using an exchange coefficient approach rather than directly using the flux on the SYRTHES side amounts to introducing a relaxation of sorts, which makes the coupling much more robust (it may introduce an error in time in case of rapidly varying temperatures, but then the coupling time scheme is explicit and not explicit, so small time steps are recommended in this case anyways).

Hoping this explanation was clear.

Thanks for the pretty picture, you seem to have everything working ! ;)

  Yvan

[Claus Andersen]

Thank you for the thorough explanation - it left me with very little to ponder. Too bad :)

So if I know from simulation that the SYRTHES simulation reaches steady state at, say 0.5sec (it's a very small solid part), the entire steady state will be reached from +0.5sec if using the same timesteps and iterations in both codes - I hope future development will allow for a restart/continuation from both codes at iteration X.

Is it possible to extract an averaged exchange coef. from a boundary face - the faces the codes share, to use for comparison? It would be really convenient for comparing a myriad of things - I'm mainly interested in heat sinks and heat exchangers and I'd hate to manually calculate it from the flow characteristics etc. 

Glad you convinced me to try SYRTHES, it is pretty straightforward to use, at least if you don't forget to use a 2nd order mesh, and not only a 1st order. Nothing like realizing that after a few hours. I will see if I can use your answers to write up something on the CAE wiki for others users - might save them some headaches.

Finally, I exchanged air with water got the simulation to converge, and very surprisingly, water cools the pins much better than air.  Imagine that.

Thanks again.

Regards,

Claus
 
Note on the attachment - air exchanged for water, same BCs as before. Only fluid  >25C (inlet temp) is shown by the volume filter.