Personal tools
You are here: Home Forum Use Weird act of MEDFileUMesh::rearrangeFamilies() ?

Weird act of MEDFileUMesh::rearrangeFamilies() ?

Up to Use

Weird act of MEDFileUMesh::rearrangeFamilies() ?

Posted by Yutaka Nishizawa at July 05. 2018

Hello, everyone. Nice to see you.

 

I am a CAD engineer trying to introduce CodeAster to my daily works.

 

To achieve this, I am writing the (unstructured) mesh file converter between our daily tool and CodeAster using MEDCoupling library (shipped with Salome-meca 2017 stable release).

In our daily tool, mechanical boundary conditions can be assigned to certain part of external face, and individual points.

So I've implemented them as level -1 group (contact) and node group to MEDFileMesh, which contains corresponding level 0 and -1 MEDCouplingUMesh.

Of course cell groups are also added to assign mechanical parameters to each material (region).

 

Checking with getGroupsOnSpecifiedLev() shows they are successfully added as follows:

    info of cell groups
       region oxfilm : number of contents = 363850
       region wafer : number of contents = 3267448
    info of face groups
       contact back : number of contents = 7920
    info of node groups
       node bottomend : number of contents = 1
       node pointend : number of contents = 1
       node topend : number of contents = 1

But after call of MEDFileUMesh::rearrangeFamilies() (recommended in document and code), a node group "back", which seems containing all nodes, appears suddenly and inexplicably:

    info of cell groups
     region oxfilm : number of contents = 363850
     region wafer : number of contents = 3267448
    info of face groups
     contact back : number of contents = 7920
    info of node groups
     node back : number of contents = 672789
     node bottomend : number of contents = 1
     node pointend : number of contents = 1
     node topend : number of contents = 1

And this node group seems to "shadow" (or override) the face group with same name "back" at saving to file.

Thus necesarry GROUP_MA information is lost.

But if I omit this call, CodeAster failes with exception deep in the core - so it seems this call is mandatory.

Could you please tell me what is happening and how can I fix this?

 

 

Any advices are hugely welcome.

Thanks,

Yutaka Nishizawa

Re: Weird act of MEDFileUMesh::rearrangeFamilies() ?

Posted by Anthony GEAY at July 05. 2018

Hello Yutaka,

It sounds like a bug into MEDFileMesh.rearrangeFamilies.

Could you please tell what getFamiliesIdsOnGroup("back") returns before calling rearrangeFamilies.

My guess is that your  "back" group is lying on family 0 which is not common.

If 0 is in list returned by getFamiliesIdsOnGroup("back") then invoke setFamiliesIdsOnGroup("back",L2) where L2 is the returned list without 0. If I'm right the call of rearrangeFamilies should be then OK.

Second question : what methods of MEDFileMesh have you been using to set the groups into MEDFileMesh object.

Best regards,

 

Anthony

Re: Weird act of MEDFileUMesh::rearrangeFamilies() ?

Posted by Yutaka Nishizawa at July 06. 2018

Hello Anthony,

Thank you so much for your kind advise!

 

I checked families ids of the groups. To my embarrasment, the result are as follows:

    info of cell groups
      region oxfilm : family ( -8 )
      region wafer : family ( -7 )
    info of contact groups
      contact back : family ( 0 )

    info of node groups
      node bottomend : family ( 6 )
      node pointend : family ( 2 )
      node topend : family ( 4 )

As you have pointed out, group "back" is lying exactly and only on family 0.

Seems I've done something wrong....

 

I have used method addGroup(int meshDimRelToMaxExt, const DataArrayInt* ids) with meshDimRelToMaxExt =-1 to add group "back".

Node groups are added with addNodeGroup.

Prior to these calls, I've set (TETRA4) cell mesh (0) and (TRI3) face mesh (-1) with method setMeshAtLevel.

Anything wrong?

 

Thank you and Best regards,

Yutaka

 

Re: Weird act of MEDFileUMesh::rearrangeFamilies() ?

Posted by Anthony GEAY at July 06. 2018

Hello Yutaka,

No your code looks perfectly correct. That's clearly a bug form my side. I'm going to try to reproduce it.

Let's sum up what you do:

1) setMeshAtLevel(0...)

2) setMeshAtLevel(-1...)

3) addGroup(0) for oxfilm and wafer groups

4)addGroup(-1...) for back group

5) addNodeGroup for bottomend pointend and topend groups

Am I right ? If not please let me know.

Sorry for the inconvenience.

Best regards,

Anthony

Re: Weird act of MEDFileUMesh::rearrangeFamilies() ?

Posted by Yutaka Nishizawa at July 06. 2018

Hi Anthony,

 

Today I've studied MEDFileMesh a bit deeper, to find that when

  1. After some groups are added to a level,
  2. All cells in a mesh of another level are assigned to a group,

reported issue occurs.

In this case, there are only one "contact" so that the level -1 mesh does not have any cells outside of "back".

Then at L1300 of MEDFileMesh.cxx, it happens that

  • ret0->empty() is true, i
  • sFamPresent is false,
  • *famId = 0.

thus family-0 group is created for "back".

 

I'm not sure this is appropriate way, but modifying

if(!isFamPresent) => if(!isFamPresent && (*famId))

seems to  resolve my current issue.

 

Do you think this quick-fix causes any trouble elsewhere?

 

Thanks and Best regards,

Yutaka

 

 

 

Powered by Ploneboard
Document Actions