-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convenience constructors CellValues and FaceValues #806
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #806 +/- ##
==========================================
+ Coverage 92.98% 93.04% +0.05%
==========================================
Files 33 34 +1
Lines 4950 4972 +22
==========================================
+ Hits 4603 4626 +23
+ Misses 347 346 -1 ☔ View full report in Codecov by Sentry. |
I absolutely like this! I very often run into the scenario where I have to manage deducing the correct geometric interpolation and it can easily lead to errors - especially for embedded elements! While I also think that Ferrite should be as low level as possible, I also think that this is now the correct level for the user-facing API. I am just indecisive if we should provide the dispatch with the quadrature order (instead of just using the quadrature rule). Maybe it is also the design of the dispatches which makes this weird. Maybe the quadrature order dispatch should be
But then I am also not sure about qr_symbol, because it changes between refshape types. |
OT: Also, if we already think about convenience functions, what about dispatches for interpolations and quadrature rules taking in the grid or grid+cellset as input argument to deduce the ref shape type? |
Happy to hear!
I see the point that this is the only thing that is not fully inferrable from the input (i.e. the symbol). But since in practice all examples use the standard I think using keyword argument is better than positional argument for this case, as I think
Interesting to explore possibilities for that too! I left a separate issue, #841 with my suggestion! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
(Taken out and extended from #680)
With the new distinction between vector and scalar interpolations since #694,
it is possible to make a convenience constructor of cell and face values, given a
SubDofHandler
(orDofHandler
with a singleSubDofHandler
).Happy to hear feedback on this idea!
Proposed syntax
where
qr::Union{Int,[Face]QuadratureRule}
. For standard quadrature rules, the syntax now allows e.g.,where
ip
is the interpolation indh
for the fieldu
,and
ip_geo
is the default geometric interpolation for the cell type indh.grid
.Using
dh::DofHandler
is only allowed for single subdofhandler problems,use
dh::SubDofHandler
for cases with multiple subdofhandlers.Motivation
The geometric interpolation matches the grid, without having to extract information by using e.g.
Ferrite.default_interpolation
on the user-sideLess verbose by not requiring the quadrature rule constructor when the standard quadrature points should be used.