[Gmsh] Error in MED format output

[Christophe Geuzaine]

Yvan FOURNIER wrote:
> 
> 
> Hello,
> 
> I would like to report 2 issues with MED output format (in Gmsh 2.4.2 
> and all older versions I have tested)
> 
> - elements are not oriented correctly, meaning they probably do not 
> follow the MED element numbering conventions.

That's possible... I think the 1st order elements are probably correct, 
though. Can you contact Nicolas Tardieu at EDF? I think he's been using 
our MED output for quite some time.

> 
> - Families in MED files do not contain groups or attributes (attributes 
> should be deprecated soon, so groups are best).
> 
> In GModel_IO_MED.cpp, we have  of the following form:
> 
> if(MEDfamCr(fid, meshName, (char*)familyName.c_str(),
>             (med_int)num, 0, 0, 0, 0, (char*)groupName.c_str(),
>             (med_int)entities[i]->physicals.size()) < 0)
> 
> The last argument of MEDfamCr should be the number of associated groups, 
> which is always 1
> if families are mapped 1-to-1 with physical entities, so I beleive the 
> call should be :
> 
> if(MEDfamCr(fid, meshName, (char*)familyName.c_str(),
>             (med_int)num, 0, 0, 0, 0, (char*)groupName.c_str(),
>             (med_int)entities[i]->physicals.size()) > 0)
> 
> 
> (i.e. the sign is wrong in the test for the original version).
> 

 From the MED documentation for MEDfamCr:

#

MEDfamCr(med_idt fid,char* maa,char *fam,med_int num,
	 med_int *attide, med_int *attval, char *attdes,
	 med_int natt,char *gro, med_int ngro)

# Paramètres :

     * fid (IN) : descripteur du fichier.
     * maa (IN) : nom du maillage.
     * fam (IN) : nom de la famille.
     * num (IN) : numéro de la famille.
     * attide (IN) : tableau des identificateurs des attributs.
     * attval (IN) : tableau des valeurs des attributs.
     * attdes (IN) : tableau des descriptions des attributs.
     * natt (IN) : nombre d'attributs.
     * gro (IN) : tableau des noms des groupes.
     * ngro (IN) : nombre de groupes.

# Code retourné : 0 si réussite, -1 sinon.


So I don't think your suggestion is correct: the routine just returns 0 
on success, -1 on error... When we create a MED file in Gmsh, we

* create one family per "Gmsh elementary entity" (geometry point, curve,
surface, volume)

* create one group per "Gmsh physical entity". If you don't define
physical entities in Gmsh, you won't have any groups in your MED file:
that's normal.


> Normally, even if entities[i]->physicals.size() == 0, Families should 
> contain a group, so
> maybe another wy of defining the group should be sued in this case, and 
> the call
> would simply be :
> 
> if(MEDfamCr(fid, meshName, (char*)familyName.c_str(),
>             (med_int)num, 0, 0, 0, 0, (char*)groupName.c_str(), 1)
> 

No: all elementary entities in Gmsh do not necessarily belong to 
physical groups...


> I have not tested the patch or built a complete GMSH compilation 
> environment,
> but I beleive this could fix the second bug (i.e. missing group 
> definitons) with MED output.
> 
> I may try to look into element node numbering for the first bug in the 
> future, but
> this may have to wait a bit.

Sounds good: please let us know if you find problems with the numbering.

At the moment the numbering is consistent within Gmsh (i.e., if you save 
a MED file and read it back the elements are correct). But we don't use 
other tools based on MED so we cannot guarantee that there isn't a 
"double mistake" in the MED numbering for some elements...

Best,

Christophe




> 
> Best regards,
> 
>         Yvan Fournier
>         EDF R&D
>         Fluid Dynamcis, Power Generation, and Environment
>         6 quai Watier - BP 49
>         78401 Chatou Cedex
>         FRANCE
> 	
> 	
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> 
> Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à l'intention exclusive des destinataires et les informations qui y figurent sont strictement confidentielles. Toute utilisation de ce Message non conforme à sa destination, toute diffusion ou toute publication totale ou partielle, est interdite sauf autorisation expresse.
> 
> Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si vous avez reçu ce Message par erreur, merci de le supprimer de votre système, ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support que ce soit. Nous vous remercions également d'en avertir immédiatement l'expéditeur par retour du message.
> 
> Il est impossible de garantir que les communications par messagerie électronique arrivent en temps utile, sont sécurisées ou dénuées de toute erreur ou virus.
> ____________________________________________________
> 
> This message and any attachments (the 'Message') are intended solely for the addressees. The information contained in this Message is confidential. Any use of information contained in this Message not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval.
> 
> If you are not the addressee, you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return message.
> 
> E-mail communication cannot be guaranteed to be timely secure, error or virus-free.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> gmsh mailing list
> gmsh at geuz.org
> http://www.geuz.org/mailman/listinfo/gmsh


-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science
http://www.montefiore.ulg.ac.be/~geuzaine