" So I am not sure how you would ever use an `Assert(...)` in optimized
release mode (where you want to run your program to get any
performance). "
I was indeed considering my program in debug mode.
Based on what you said, there is no way for me to catch
the failed .reinit call in optimized releas
Have you considered looking into our FEPointEvaluation [1] and related
"nonmatching" facilities?
I have the feeling that we already provide the right data structures for
your interpolation/evaluation needs - in particular with an efficient
and fast implementation. An example usage can be found in
I am a bit confused.
In optimized release mode the `Assert` are reduced to a nnop and will
not abort (or throw an exception). For user-visible/induced runtime
errors we have `AssertThrow` which will throw an exception (and not
abort a program). In summary:
- we use `Assert(...)` in the library
Hello,
I would like to use the NonMatching::QuadratureGenerator class
directly, as I need to generate multiple (as in many!, unfortunately)
nonmatching quadratures for the same cell. Therefore I would like to avoid
the route of interpolating the level set function onto the whole mesh etc,
as
Jost,
For looping on the boundaries, you'll have to write an extra lambda amd
pass that to the MeshWorker.
You can look at step 12 or 74 for this.
Also following this cause I want to know what are the MeshWorker
alternatives since I am relying heavily on it in my code
Best,
Abbas
On Thursd
Let me please clarify my last concerns in this regard:
The operations
GridTools::find_active_cell_around_point and
feValues.reinit
are executed at quadrature point level and performance
is really important in our application.
The reason why I wanted to use an
try/catch block is to surrogate the u
Thanks for the quick response!
Would you suggest me to read more tutorials on how the MeshWorker works to
fix this issue then or try to set up my program without a MeshWorker? I
thought I had set it up correctly and tried already for a while to figure
out what I did wrong. Also I Initially only
On 8/3/23 04:54, 'Jost Arndt' via deal.II User Group wrote:
for (unsigned int f = 0; f < GeometryInfo::faces_per_cell; ++f)
{
if
(cell->face(f)->at_boundary())//(face->at_boundary())
{
On 8/3/23 05:01, Najwa Alshehri wrote:
The first scenario involves directly using the FeFieldFunction when my
computed solution consists of a single component. In this case, I have
successfully calculated the L2 and H1 norms of the error using the
`integrate_difference` and `compute_global_erro
On 8/2/23 15:58, Simon Wiesheier wrote:
Does that make sense?
Or do you see a better solution, like checking
cell->status() right after GridTools::find_active_cell_around_point?
This. If the function you call returns an error code in the form of an end
iterator, just test for that rather than
Dear team,
I want to express my gratitude for the support you have provided thus far.
I would like to provide you with an update on the current situation and
seek your assistance regarding a couple of issues.
Firstly, I have successfully implemented the missing function
`VectorFunction
Hi there,
so far I had a great learning curve, but now i seem to be stuck.
I try to solve my own little PDE, which is a system of multiple nonlinear
time dependent equations and read through plenty of the Tutorials.
Using Dirichlet-Boundary conditions everything worked out finally, now I
wanted
12 matches
Mail list logo
