Problem with output MED file

[Luigi Giaccari]

Hi all,
 
I am a code_saturne beginner and 2 months ago I started using code_aster. What I am trying to do now is to chain the 2 of them. I read a couple of posts in this forum about this topic but I found nothing straight to my point.
The problems I am having are the following:
 
- I don't know how to return pressure values on walls. Walls are already defined as group in the input mesh file. They seem to disappear in the output.
I was only able to return "Efforts" as text file but only for the whole boundary. by the way I can not use them, since I don't know the nodes id relationship betweeen them and the wall group in med file.
 
- when I try to use the LIRE_CHAMP into aster I get:
 
!-------------------------------------------------------!
! <EXCEPTION> <DVP_97> !
! !
! !
! Erreur signalée dans la bibliothèque MED !
! nom de l'utilitaire : EFFOCO !
! code retour : -1 !
! !
! !
! !
! !
! Il y a probablement une erreur dans la programmation. !
! Veuillez contacter votre assistance technique. !
!-------------------------------------------------------!


Destruction du concept 'ForceFie'.

!-----------------------------------------------------------------------!
! Liste des alarmes émises lors de l'exécution du calcul. !
! !
! Les alarmes que vous avez choisies d'ignorer sont précédées de (*). !
! Nombre d'occurrences pour chacune des alarmes : !
! aucune alarme !
!-----------------------------------------------------------------------!
 
thanks for your attention and most of all for your great softwares!
Luigi

[Yvan Fournier]

Hello,
If you activate output of postprocessing (whether in the GUI or setting ichrbo = 1 in usini1.f90), you should get output of the pressure variable (as well as "effort" vectors including both normal pressure and viscous forces) on a secondary MED file. This will still utput values on the whole mesh.
For finer-grained control, you should use the usdpst.f90 (and possibly usvpst.f90) user subroutines. USDPST will allow you to generate an output on the selection criteria of you choice ('WALL' group in you case), and USVPST allows selecting or buiding and outputting new variables on this submesh. With version 2.0-rc1 and above, you may also use the 'PSTCAT' function in USDPST (seeand adapt the example in usdpst.f90) to opt to output the same variables on the wall mesh as on the full boundary (whether you output the full boundary or not), so you don't even need to use USVPST if you want to avoid "too fine" control.
Im am not sure if Code_Aster requires you to filter efforts on the wall or if it can interpolate on the whole boundary (in which case you don't need to bother with user subroutines). Efforts off the wall will have value zero.
Best regards,
  Yvan

[Luigi Giaccari]

Thanks Yvan,
 
I already set the output field request to Efforts.  I did not not know they also considered the viscous effect: THAT'S GREAT!
 
Since as you said they are 0 out of walls I wont bother with Fortran ( Please switch to C++ :-) ) to get the Wall only output.
 
I gonna go this way: set output request to a med file with only the boundary. Then I will project the Efforts field on the original 3D mesh. It should work, I hope!
 
I am currently struggling on how to extract such field in Aster ( I posted a thread on the forum: http://www.code-aster.org/forum2/viewtopic.php?id=14448
)
 
I have another secondary problem: how to choose the output file-path or at least the file-name?

In this case I bet I have to deal with Fortran SIGH :-( !

[Yvan Fournier]

Hello,

Yes, if you want to create files with other names than the defaults, you need to go with the user subroutines. They are in Fortran, but since there is not much more to do than edit strings such as path names based on the examples given, you won't feel as if you were forced to program a complex algorithm in Fortran (note that in the future 2.1 version, some C user subroutines will appear in a few places, though no C++ is planned).

Note also that variables output by Code_Saturne are cell or face-based, and not node-based (with the exception of nodal displacements in case of ALE calculations, but output of node-base values is not currently accessible through user subroutines, as only the C API in cs_post.c is defined). I do not know if this could be an issue in Code_Aster, but accessing variables output from Code_Saturne has been done before by other users (with older versions of both Code_Saturne and code_Aster), so you issue is probably a variable naming or query issue (or possibly a bug) more than a fundamental limitation.

Best regards,

Yvan

[Luigi Giaccari]

I give you a little feedback:
From code_aster forum they told me:
"aka the MED standard is not followed : if you use mdump, you see the
field Efforts is said to have only 1 component but, in fact, it has
tree"
Did you experienced any compatibility problem with med file before?
I noticed Salome is capable of opening them, the problem comes with aster.
Thanks anyway for you support.

[Yvan Fournier]

Hello,

I checked that mdump only shows me the name of the first component, but this is due to putting null (end of string) instead of whitespace characters at the end of each component name (C vs Fortran habits). If I simply change this, I see all 3 components (I just verified this). I'll check with the MED developpers if they have recommendations, but to me, this is simply a bug in mdump, not in our output.

And mdump does not tell you how many components a field has (it should be improved), so looking at the component names is not a good way of determining how many components we have (I howe Code_Aster does not do it this way).

A possible explaination for the issue might be interlaced/non-interlaced fields. Code_Saturne writes interlaced vectors in its MED output (whether the variable is interlaced or not in memory), but I do not know if Code_Aster handles both interlaced/non-interlaced, or if it expects something else. If this were the case, separating the field into its components and writing it as 3 scalars would be a solution (you might be able to do this under SALOME from an existing file).

Best regards,

  Yvan

[Luigi Giaccari]

I don't thing I can handle that, my knowledge of .MED at this stage is very poor.
 
Anyway I have seen peoples on forums talking about the chain aster/saturne and they never say anything about .med compatibility. Probably I am just missing something trivial, I will let the project rest for a few days and then restart with a new fresher mind.
 
In the meantime I will travel forums in search of useful news.
 
Thanks Yvan,
 
Vive la France and code_saturne!
 
Luigi

[Luigi Giaccari]

The MED file is OK ( I suppose!).
 
I am now able to extract pressure data, still unable to extract efforts.
I had trouble projecting the results form one mesh to another because of shell elements. After removing them everything is OK!
thanks for your support!
Luigi

[David Monfort]

Great to know ;)
Thanks for the report!
David