-
Notifications
You must be signed in to change notification settings - Fork 90
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
Add apply_analytical! function #532
Conversation
Codecov ReportBase: 92.81% // Head: 93.04% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #532 +/- ##
==========================================
+ Coverage 92.81% 93.04% +0.23%
==========================================
Files 24 25 +1
Lines 3978 4039 +61
==========================================
+ Hits 3692 3758 +66
+ Misses 286 281 -5
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
I think a more general name would be better since this is not only useful for initial conditions. For example in the homogenization example: Ferrite.jl/docs/src/literate/computational_homogenization.jl Lines 519 to 522 in 8e447e2
This seems to be simply to transfer an analytical function to FE space (without doing the L2 projection or solving the pertinent |
Good point! |
This seems to only work correctly for pure ODE systems. Algebraic constraints in e.g. DAEs may be a problem, especially enforcing the correct compatibilities between the fields. We should at least document this if you want to merge this. |
Do you mean that it is difficult for the user to define the correct functions I can write a short section about using this for initial conditions, and add a warning there about the compatibility. Do you have a suggestion for an appropriate section? |
Indeed, that is my point - writing down these equations for the algebraic portion can be super painful. Usually it is simpler to just provide the solution to the ODE portion of the problem and let the initializer figure out what the compatible solution to the algebraic equations are. At least that is how it is usually handled by DAE solvers. Not sure what the best approach would be here, though. |
Maybe worth it to compress the gif a little if you haven't already since it doubled in size |
I tried autocompression (from 30MB->7MB), now I did manually - doesn't look so nice, but at least much smaller. |
Ah sorry forgot to mention. We usually utilize gifsky for compressing the gifs. From our experience the file size is small and visual is still great. |
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.
Left some comments :)
src/Dofs/apply_analytical.jl
Outdated
for (i,x_node) in enumerate(coords) | ||
x_dof += value(ip_geo, i, refpoint) * x_node | ||
end |
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.
Feels like this exist somewhere, maybe BCValues
?
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.
Yes,
Ferrite.jl/src/FEValues/face_values.jl
Line 264 in 2f86559
M[i, qp, face] = value(geom_interpol, i, ξ) |
and
Ferrite.jl/src/FEValues/face_values.jl
Line 278 in 2f86559
x += bcv.M[i,q_point,face] * xh[i] # geometric_value(fe_v, q_point, i) * xh[i] |
but this seems specialized for faces? In that case, we would call
f(x)
even more times?(I can create a similar construct pre-caching the geometric shape values at the reference points if desired, but I feel the code will become complicated then. )
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.
I see. Perhaps one could create a CellValues
with a quadrature rule that has the reference nodes as quadrature points then.
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.
Introduced CellDofValues
now.
I'm not sure about the name (as usual), but it is internal.
Co-authored-by: Fredrik Ekre <[email protected]>
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, but looks like CellDofValues
could be removed?
src/Dofs/apply_analytical.jl
Outdated
ip_fun::Interpolation, ip_geo::Interpolation, f::Function, cellset) | ||
|
||
coords = getcoordinates(dh.grid, first(cellset)) | ||
cdv = CellDofValues(ip_fun, ip_geo) |
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.
Seems like this could simply be CellScalarValues
with a custom quadrature rule with points in the reference coordinates?
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.
OK, I'll look into that when I have time.
I guess this should be a form of 1st order lobatto quadrature then. But since this is not implemented for RefTet I have to think a bit how to fix that.
Will ping once fixed!
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.
You can just plug whatever coordinates you want in a "fake" quadrature rule, and think of them as "points for evaluation" instead of quadrature points, for example
julia> using Ferrite
julia> ip = Lagrange{2,RefTetrahedron,1}();
julia> points_for_evaluation = Ferrite.reference_coordinates(ip);
julia> fake_quadrature_rule = QuadratureRule{2,RefTetrahedron,Float64}(fill(NaN, 3), points_for_evaluation);
julia> cellvalues = CellScalarValues(fake_quadrature_rule, ip)
CellScalarValues{2, Float64, RefTetrahedron} with 3 shape functions and 3 quadrature points
You can add a constructor like
function QuadratureRule{D,R}(weights::AbstractVector{T}, points::AbstractVector{Vec{D,T}}) where {D, R, T}
QuadratureRule{D,R,T}(weights, points)
end
to make it easier (no need to specify T
) (see also #513).
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.
Thanks for those tips - now I also learned how to do custom quad rules!
I reduced away the dim input in the constructor as well - hope that is ok!
Ferrite.jl/src/Quadrature/quadrature.jl
Lines 43 to 46 in 4f85093
function QuadratureRule{shape}(weights::AbstractVector{Tw}, points::AbstractVector{Vec{dim,Tp}}) where {dim, shape, Tw, Tp} | |
T = promote_type(Tw, Tp) | |
QuadratureRule{dim,shape,T}(weights, points) | |
end |
Co-authored-by: Fredrik Ekre <[email protected]>
Seems like more users may find this convenient, e.g. #434
In contrast to the solution in #434, this solution also supports different function and geometric interpolations.
Remaining