Question about outputting elem information?

[PengWei97]

Dear MOOSE Experts,

I have some questions about outputting element information. Although it is relatively simple, I look forward to your reply.

In moose's simulation, I output elem information, using std::cout << *_current_elem << std::endl;, and browsed std::string libMesh::Elem::get_info() const. But the information output to the screen is not very clear, and the element information output to the screen is as follows,

  Elem Information
   id()=203, unique_id()=401, processor_id()=0 
      // dof_id_type _id; processor_id_type _processor_id; unique_id_type _unique_id;
      // _id The id of the DofObject.
      // _unique_id: A globally unique id, guaranteed not to change as the mesh is repartitioned or adapted.
      // 
   type()=QUAD4
   dim()=2
   n_nodes()=4
   mapping=LAGRANGE_MAP # largrange_map
    0  Node id()=195, processor_id()=0, Point=(x,y,z)=(     375,        0,        0)
    DoFs=(0/0/0) (0/1/1) (0/2/2) (0/3/3) (1/0/0) 
    1  Node id()=8, processor_id()=0, Point=(x,y,z)=(     400,        0,        0)
    DoFs=(0/0/4) (0/1/5) (0/2/6) (0/3/7) (1/0/1) 
    2  Node id()=197, processor_id()=0, Point=(x,y,z)=(     400,  83.3333,        0)
    DoFs=(0/0/8) (0/1/9) (0/2/10) (0/3/11) (1/0/2) 
    3  Node id()=196, processor_id()=0, Point=(x,y,z)=(     375,  83.3333,        0)
    DoFs=(0/0/12) (0/1/13) (0/2/14) (0/3/15) (1/0/3) 
   n_sides()=4
    neighbor(0)=nullptr
    neighbor(1)=214
    neighbor(2)=205
    neighbor(3)=202
   hmin()=25, hmax()=87.0026
   volume()=2083.33 // h*l
   active()=1, ancestor()=0, subactive()=0, has_children()=0
   parent()=43
   level()=2, p_level()=0
   refinement_flag()=DO_NOTHING
   p_refinement_flag()=DO_NOTHING
   DoFs=(1/1/36) (1/2/37) (1/3/38) (1/4/39) (1/5/40) (1/6/41) (1/7/42) (1/8/43)

So my question is what does id()=203, unique_id()=401, processor_id()=0 mean?

Any suggestions or recommendations to fix these problems would be greatly appreciated.

Thanks

Wei

[roystgnr]

Each DofObject (node or elem) in a mesh has an id(), which is the fastest way to look it up and which libMesh uses to identify it internally. The set of ids in a mesh is typically very dense, and is often (except when objects have been deleted and not replaced or renumbered afterward) contiguous. This id may be changed mid-simulation if the mesh is changed in such a way to trigger renumbering, unless renumbering is disabled first.

If libMesh is configured with --enable-unique-id (as MOOSE does), each object also has a unique_id(). libMesh provides this but doesn't use it internally. An object's unique_id will never change, unless the object is deleted entirely and a new one created in its place. The set of unique ids on a mesh is usually very sparse.

If libMesh is configured with MPI support (as MOOSE also does), each object on a mesh belongs to a "processor", an MPI rank. When the mesh is "partitioned" during standard preparation while running in parallel, objects are assigned to be "owned" by different ranks; the processor_id() is the number identifying that rank (on the communicator which was used to create the Mesh, which is the communicator used to initialize libMesh by default, which is MPI_COMM_WORLD by default).

[PengWei97]

Hi @roystgnr, thank you very much for your thoughtful reply.

The set of ids in a mesh is typically very dense, and is often (except when objects have been deleted and not replaced or renumbered afterward) contiguous.

During the calculation process, will the mesh's refinement and coarsening make the node or elem ID disappear or rearrange?

If libMesh is configured with MPI support (as MOOSE also does), each object on a mesh belongs to a "processor", an MPI rank.

When I run an example in moose, 480 QUAD4 type elements and the first-order Lagrangian shape function are used to get the number of times the materials object in moose is called. The situation is as follows,

• Do not use parallel computing, only use one logical core (1 rank), in the INITIAL stage, the number of times the material object is called is 480*4/1=1920;
• Using parallel computing, call 20 logical cores (20 ranks), in the INITIAL phase, the number of times the material object is called is 480*4/20=96, and the information output by *_current_elem only has processor_id( )=0, and no processor_id()=1 or other;

So my question is whether this material class is only called on rank 0, and whether 4 in the above calculation method is related to the selected shape function, because I found that the index of the quadrature point [_qp] is 0~3.

Finally, since I needed to develop some of my own models based on moose's existing models, I found that there was a lot of libmesh-related code to understand. So I would like to ask if there are any suggestions and information to share for a libmesh rookie like me?

Thank you very much for your kind help. I will raise my questions promptly and look forward to your further guidance.

wei

[roystgnr]

During the calculation process, will the mesh's refinement and coarsening make the node or elem ID disappear or rearrange?

Unless you disallow it via a MeshBase API, yes; we typically do renumbering to keep IDs in contiguous blocks on each processor, which means they can change entirely when the mesh is repartitioned for load-balancing.

the information output by *_current_elem only has processor_id( )=0, and no processor_id()=1 or other;

By default libMesh redirects cout on all but processor 0, so users can simply cout << "Some informational message" without wrapping it in if (some.processor_id() == 0) every time. If you want a message to appear from every processor you can use cerr, synchronize it to processor 0, or use --keep-cout on the command line.

I found that there was a lot of libmesh-related code to understand. So I would like to ask if there are any suggestions and information to share for a libmesh rookie like me?

I'm afraid the documentation at the libMesh level isn't as good as at the Moose level; there's still Doxygen available, but that's more of a reference than a tutorial. Reading through some of the libMesh examples might be helpful.

[PengWei97]

Ok, thank you very much for the guide. I will read through the libmesh examples and Doxygen to learn more about libmesh. There may be further questions, but expect more advice here.

[RocksSavage]

To anyone who is working directly with libmesh's Elements / Dofobject classes, here is an addendum to the excellent answer already given. The MeshBase (Replicated or Distributed meshs) uses it's node's id() as their index in the array of nodes the mesh keeps internally. Therefore the id() cannot be arbitrary, and if you are needing to create new nodes/points, it is better to let the mesh class set the id() itself automatically.

There is no build-in method to query a mesh for a node of a given unique_id(). This is probably why libmesh doesn't use them internally, since usually if you manually set an ID for something, it is because you want to find it again later.

[jwpeterson]

This is probably why libmesh doesn't use them internally,

Turning on unique_ids is still a configure-time option, so we don't use them for much internally because any such code would have to be wrapped in #ifdef guards, and/or need some kind of fallback algorithm for when unique_ids are not available.

[roystgnr]

if you are needing to create new nodes/points, it is better to let the mesh class set the id() itself automatically.

Usually, yes. Even if you're creating new nodes in a distributed manner on a distributed mesh, you can let the mesh assign local ids automatically, you just then do a separate communication step to communicate those ids to other processors that need to ghost those nodes. But there's one exception: if you can come up with your own consistent a priori id numbering then it's more efficient to use that. See MeshTools::Generation::build_extrusion for an example: extrusion here is almost "embarrassingly parallel", because after the first parallel_max_unique_id() call is done, we have a rule for calculating every new id and unique_id, and that lets ghosted nodes and ghosted elements be constructed without having to communicate with their owners.