plot_model_3d check nen instead of specific element types

[mhscott]

It appears plot_model_2d checks number of element nodes (nen) to determine what to plot, but plot_model_3d checks specific element types instead of nen, so, for example ShellMITC4 elements are not plotted in 3d.

[sewkokot]

@mhscott, thank you reporting this bug. In two days I will upload the refactored version of opsvis which includes the fix and entirely relies on the element types (classtags).

[firai]

Is the decision to use element types by default rather than the number of nodes related to zero-length elements? I understand that there's a significant number of custom element types in the wild (I suppose only built for the Tcl executable for the time being, but that will probably change over time) and that elements are being added regularly even to the core OpenSees code, so only recognizing elements by element types could require constant code maintenance to incorporate new types in opsvis and custom copies of opsvis for custom OpenSeesPy builds.

I would suggest adding a fallback for unrecognized elements that draws the element based on the number of nodes (at least for common/existing node counts), so that unrecognized elements are shown by default rather than hidden by default.

I could work on a PR that adds this fallback, but if a major rewrite is getting pushed soon, then I should probably wait until the new code is pushed.

[sewkokot]

@mhscott I have uploaded the refactored and hopefully improved version of opsvis. The approach for plotting OpenSees elements has been changed and now there should be no errors in case of unsupported elements are encountered.

@firai Yes, a PR for the fallback for unrecognized elements is welcome, but keep in mind that the nodes of some elements are not obvious how to plot them (eg. Joint2D /5 nodes/ or MVLEM_3d /the order of nodes/). The other approach would be to plot only nodes of unsupported elements?

[firai]

@sewkokot Thanks for your response. My proposal is to have the fallback option(s) available for elements with common node counts (2 nodes, 4 nodes, etc.), just to reduce the likelihood that new elements require opsvis modifications to visualize. I agree that this fallback would not replace the custom handling that's required for specific elements with peculiar attributes.

Regarding 5-node elements, out of curiosity, are there any other (commonly used) elements that have 5 nodes? @mhscott, maybe you can advise as well?

Regarding MVLEM-3D, I see that the opsvis code flips the order of the last two nodes when graphing. However, it seems from the documentation (1, 2, 3, 4) that the node input order and DOF numbering are both counterclockwise, which seem to be similar as Quad and Shell elements. What am I missing here? Does eleNodes() report the nodes for these elements in a different order than as-input?

[sewkokot]

@firai, For the MVLEM_3D element, eleNodes() returns the externalNodes vector which is in a different order than the node order in the OpenSees command.

In MVLEM_3D.cpp we can found the following comment:

    // Assign node tags to external nodes - Node ordering switched on purpose to match the theoretical derivation
    externalNodes(0) = Nd1;
    externalNodes(1) = Nd2;
    externalNodes(3) = Nd3; 
    externalNodes(2) = Nd4;