>
> [...]
> This means everything we do in DataPostprocessor is evaluated directly in
> the mapped Gauss points which is actually the reason why we use this
> postprocessor approach. We want to map the solution of quantities stored on
> the Gauss points to the physical nodes, so we can visualiz
I checked the Gauss points within my normal computation using FEValues and
compared them with the evaluation points from the DataPostprocessor:
GAUSS POINT COORDINATES
0.211325 0.211325
0.788675 0.211325
0.211325 0.788675
0.788675 0.788675
EVALUATION POINTS
0.00 0.00
>From what I learned, all information we obtain from FEValues is
automatically mapped from the unit cell to the physical space/coordinates.
By patch vertices you mean the nodes of each element, hence
DataPostprocessor gives me the gradients with respect to the mapped gauss
points to the nodes o
>From what I learned, all informtion we obtain from FEValues is
aoutomatically mapped from the unit cell to the physical space/coordinates.
By patch vertices you mean the nodes of each element, hence
DataPostprocessor gives me the gradients with respect to the mapped gauss
points to the nodes o
>
> Using the postprocessor approach according to step-33 I have computed the
> strain tensor successfully by means of the
> Postprocessor::compute_derived_quantities_vector function and its
> displacement gradient duh.
>
> Unfortunately, within an arbitrary function called right after I solve
Hi,
Using the postprocessor approach according to step-33 I have computed the
strain tensor successfully by means of the
Postprocessor::compute_derived_quantities_vector function and its
displacement gradient duh.
Unfortunately, within an arbitrary function called right after I solve the
syst
Hi,
Using the postprocessor approach according to step-33 I have computed the
strain tensor successfully by means of the
Postprocessor::compute_derived_quantities_vector function and its
displacement gradient duh.
Unfortunately, within an arbitrary function called right after I solve the
syst
