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

 

 

 

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

Posted by Anthony GEAY at July 23. 2018

Hello Yutaka,

Sorry for the delay !

You're patch is absolutely right ! I've commited your patch into master branch of medcoupling for medcoupling9.2.0.

I've also added a check into rearrangeFamilies method in case of such a case happen. Finally, I've added a non regression test based on your usecase.

Sorry again for your time lost due to this bug and thank you for helping me to solve this bug.

Best regards,

Anthony

Powered by Ploneboard
Document Actions