Default class Element attribute value

[dbgarlisch]

When we export MFEM from Fidelity Pointwise, if the user does not explicitly provide a boundary condition (BC) ID value, we export the "magic" value of 2147483647 (max int) which is the Unspecified ID.

boundary
22
2147483647 3 18 19 17 16
2147483647 3 20 21 19 18
   ...snip...
2147483647 3 2 3 5 4
2147483647 3 0 1 3 2

We have a customer reporting that the 2147483647 value is causing problems:

"Unfortunately this mesh does not seem to be working either. I strongly suspect it is because the boundary attribute is set to 2147483647 in this file. Is this an exported mesh without any BCs specified in Pointwise? If so, then maybe it would be best for having specified BCs to be a requirement at export."

If I understand the MFEM code correctly, this value is stored in the Element::attribute data member. I see that Element::attribute is set to 1 in the Element constructor.

What is the valid range for Element::attribute ?

Do you have a suggestion for which value should be used by Fidelity Pointwise to represent the Unspecified attribute?

Fidelity Pointwise auto-numbers BC IDs starting at 1. However, the end-user can change the ID to any valid integer value. Ideally this Unspecified ID value would be something that would not be normally used by an end-user.

thanks for your help!

[mlstowell]

Hi, @dbgarlisch,

The range of valid attribute IDs is from 1 to max(int). In theory your "magic" number should work fine. However...

It's not uncommon in MFEM to find what we call "marker arrays" which have a length equal to the maximum attribute number. I'm sure you see the potential for problems. It might be wise for MFEM to scan the attribute numbers and look for potential problems of this sort and at least issue a warning. Perhaps in the longer term we might even want to move away from using these marker arrays. In the near term I'm afraid you'll need to find another solution.

MFEM doesn't have the concept of an "unspecified boundary ID". In such cases we simply don't include these boundary faces as "boundary elements". This successfully avoids the problem but it does create another issue which you should be aware of. Specifically, by default GLVis visualizes fields only on boundary elements. Consequently, faces which physically exist on the surface of the mesh but are not included as "boundary elements" appear as holes in the GLVis representation. This may be acceptable particularly if GLVis support is not needed or if unspecified boundaries are uncommon.

Another solution, and one that we have employed from time to time, is to choose an attribute number a little larger than the user-specified attribute numbers and assign this to unspecified boundary elements. It could be any number that the user hasn't assigned. I see the virtue of the Fidelity PointWise choice but I don't think MFEM can match that for recognizability. Perhaps the closest we could provide would be a sequence of 9s larger than the maximum user-specified ID. Assuming the user hasn't chosen very large integers (which does happen) this could work.

Unfortunately we do need to consider the overhead required to occasionally allocate, scan, and deallocate integer arrays of length max(attribute).

Best wishes,
Mark

[dbgarlisch]

@mlstowell

Thank you for the quick reply.

What would happen if the attribute was set to zero?

As we have done for other exporters with similar aversions to max int, we considered mapping the unspecified ID to maxUserSpecifiedID+N. The drawback is that the unspecified value can change from one export to the next if the user adds BCs. This can create difficulties for automated iterative/adaptive meshing applications.

Since there is no MFEM support for an unspecified ID, we will use the +N approach and issue a warning message.

Thanks again!

[mlstowell]

Hi, @dbgarlisch,

We use the attribute ID to lookup values in the marker arrays. In other words we access marker[attr-1]. I'm fairly certain we don't always check these attribute IDs to make sure they are in the valid range (unless MFEM_DEBUG is ON) so the marker array would be indexed at -1 and cause a segmentation fault (an optimization which may not be worth the headaches but that's another debate...).

Best wishes,
Mark

[dbgarlisch]

<braindump>
If marker arrays are allocated with size MaxAttr+1 and the marker ptr is moved to point to &marker[1], then marker[attr-1] will not segfault for attr = 0. Now, 0 can be used as the UNDEFINED attr.

This will be backward compatible since 0 was previously illegal.

This will only effect the (few?) places where the arrays are allocated, not the many places where they are used/indexed.

All this assumes marker arrays are simple allocations (not objects). The simple array ptr manipulation can be managed with methods like:

template<typename T>
bool newMarkerArray(const size_t maxAttr, T* &p)
{
    if (maxAttr != std::numeric_limits<size_t>::max()) {
        p = new T[maxAttr + 1];
        ++p; // Make p point to p[1]
    }
    else {
        p = nullptr;
    }
    return nullptr != p;
}


template<typename T>
void deleteMarkerArray(T* &p)
{
    if (nullptr != p) {
        delete --p;
    }
}

This works best for dense marker arrays where most/all entries are used.

I have ideas for sparse marker array classes. I will leave those ideas for another discussion.
</braindump>