add a note in the grid section about anti-clockwise ordering

[koehlerson]

something like this maybe? #515

[termi-official]

Can the error message contain a link to this?

[KnutAM]

Nice!
At least I haven't found it, so it would be nice to document Ferrite's ordering scheme.
Then, as @termi-official says but instead refer to the ordering scheme in the docs in the error message.
And then I would say that the note is no longer necessary. But until then, this would be good to have!

[koehlerson]

Nice! At least I haven't found it, so it would be nice to document Ferrite's ordering scheme.

In the docs the quadrilateral ordering is introduced in anti-clockwise ordering, but I agree that could be written down explicitly with a reference to reference_coordinates

[fredrikekre]

Would be good with some plots for every element type (and interpolation) with numbering. Perhaps this can be done with Makie or FerriteViz?

[koehlerson]

there is at least an issue about it :D Ferrite-FEM/FerriteViz.jl#15

[koehlerson]

So I would do something like this? Will include the local face and edge number and maybe I can make some markers for the dofs, but I'm not sure about it, will probably be a bit harder

[fredrikekre]

That looks great. I don't think dof markers are necessary, they follow the same order

[termi-official]

While they follow the same ordering the exact dof numbering can be different if we have different interpolations for geometry and the solution. Also note that dofs can also be associated to higher order entities than only nodes.

[codecov-commenter]

Codecov Report

Patch coverage has no change and project coverage change: +0.02 🎉

Comparison is base (f6c7e23) 92.34% compared to head (06153e5) 92.37%.

❗ Current head 06153e5 differs from pull request most recent head 36b1abb. Consider uploading reports for the commit 36b1abb to get more accurate results

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #517      +/-   ##
==========================================
+ Coverage   92.34%   92.37%   +0.02%     
==========================================
  Files          22       22              
  Lines        3762     3776      +14     
==========================================
+ Hits         3474     3488      +14     
  Misses        288      288              

see 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[termi-official]

Maybe as followup we can provide an example to find the flipped elements in FerriteVis.jl. Should be very straight forward (i.e. plot L2 element of order 0 with value of det(J)).

[koehlerson]

Maybe as followup we can provide an example to find the flipped elements in FerriteVis.jl. Should be very straight forward (i.e. plot L2 element of order 0 with value of det(J)).

What do you mean by this? The flipped elements only occur if you read yourself a mesh 🤔

[termi-official]

AFAIK we currently only have a guarantee that elements are not flipped if we utilize the provided grid generators, yes. But I think it might be helpful to plot the determinants and hence detect flipped elements.

[KnutAM]

LGTM otherwise, but I don't feel experienced enough to press the approve button :)

[lijas]

Should we add a note about note ordering here aswell, and maybe a link to the docs? :P

Ferrite.jl/src/FEValues/common_values.jl

Line 17 in 2f86559

@noinline throw_detJ_not_pos(detJ) = throw(ArgumentError("det(J) is not positive: det(J) = $(detJ)"))

[KnutAM]

I think it is a nice PR that would be nice to get merged! I've closed my previous concern above.

Should we add a note about note ordering here aswell, and maybe a link to the docs? :P

My suggestion would be to change:
"det(J) is not positive: det(J) = $(detJ)"
to
"det(J) is not positive: det(J) = $(detJ) (hint: check node ordering)"

A merge with master would be needed as well

@koehlerson: Let me know if you want me to do anything!

[koehlerson]

I can finalize it, I wasn't sure how to deal with the gh-page branch upload, so if this should be merged with a ref to the gh-pages upload, let me know

[KnutAM]

I wasn't sure how to deal with the gh-page branch upload, so if this should be merged with a ref to the gh-pages upload, let me know

I think it can be merged in any way as I think including FerriteViz in the doc is possible now with Julia 1.9.
Edit: And it is of course nice that it will update in case something changes in Ferrite (+ that the code to generate the figure is available, so I like your initial solution!)

Previously, I've uploaded figures to the gh-branch assets folder and added the figures to the list of downloads. But sometimes the download fails, don't know why though.

[termi-official]

The JSServe bug does not affect this PR, because on the current FerriteViz release we have an older Makie version, right?

[koehlerson]

The JSServe bug does not affect this PR, because on the current FerriteViz release we have an older Makie version, right?

No it's not related, since it uses CairoMakie and you only need JSServe for WGLMakie and interactivity stuff of the plot

[termi-official]

Ah, you are right. Thanks.

[koehlerson]

need Ferrite-FEM/FerriteViz.jl#78 before rebasing and merging