unused member `CPhysicalGeometry::Local_to_Global_Marker`

[maxaehle]

From searches in the code of the develop branch, I suspect that the members
unsigned short Local_to_Global_Marker{nullptr}; /!< \brief Local to Global marker. */
unsigned short Global_to_Local_Marker{nullptr}; /!< \brief Global to Local marker. */
of CPhysicalGeometry are not initialized anywhere in the code right now.

Apart from this, from a comparison with Global_to_Local_Point I would infer that G_to_L_Marker should be of type unordered_map<unsigned short, unsigned short>, depending on the intended functionality of course.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If this is still a relevant issue please comment on it to restart the discussion. Thank you for your contributions.

[maxaehle]

While unsigned short* CPhysicalGeometry::Local_to_Global_Marker and Global_to_Local_Marker are currently not in use, I think that they should be filled with sensible content rather than being removed. The data seems to be already available in CPhysicalGeometry::LoadSurfaceElements with the local variables
- vector<unsigned long> Marker_Local and
- unordered_map<unsigned long, unsigned long> Marker_Global_to_Local.

I'd like to implement this change. Before that, let's discuss the following questions: Do you think that marker IDs (often called iMarker) should be unsigned short or unsigned long (this is inconsistent across the code)? Should the above data structures be arrays (with some special code for "this global index does not correspond to a local index") or maps/lists? I'd prefer the latter, respectively.

[pcarruscag]

I think in LoadSurfaceElements the SendRecv markers do not exist yet.
unsigned short is what we use most for marker. Local to global should be an array or vector, global to local should be an unordered map, exactly as done for the point and element maps.

[pcarruscag]

Access to the global to local should be via a function to avoid unintentional insertion.

[maxaehle]

Thanks for your hints. Now I understand that:
a) In CPhysicalGeometry::LoadSurfaceElements, the process finds those global markers that have at least one element adjacent to the subdomain of the process, and assigns local IDs. The function is called in the constructor of CPhysicalGeometry.
b) The transfer of quantities from one MPI process to another is done with additional markers of type SEND_RECEIVE. They are created e.g. in CPhysicalGeometry::SetSendReceive => after the constructor has been called.

I also saw that the problem of mapping local (non-SEND_RECEIVE) markers to some global identifiers can be (and is) solved by the string config->GetMarker_All_TagBound(val_marker). And probably there is no point in assigning a global ID to each pair of communicating SEND_RECEIVE markers.

So there is no need for the local<->global mapping that I intended to implement. Instead I will just remove the two members of CPhysicalGeometry and what depends on it.

[pcarruscag]

And that string is more easily used to retrieve some property of e.g. a heatflux marker, whose number is again different from total and local.