Skip to content

Calculator app improvements#4027

Merged
roystgnr merged 24 commits intolibMesh:develfrom
roystgnr:calculator_error
Dec 12, 2024
Merged

Calculator app improvements#4027
roystgnr merged 24 commits intolibMesh:develfrom
roystgnr:calculator_error

Conversation

@roystgnr
Copy link
Copy Markdown
Member

@roystgnr roystgnr commented Dec 2, 2024

I've been using this for various tests recently, and both the infrastructure upgrades and the app upgrades are likely to be useful to others too.

We might have a solution that depends on other variables or other
systems.
This is necessary for compatibility if we want WrappedFunctor to work
with any plain FunctionBase subclass that has an init() overload.
Yo, dawg, I heard you like Adapter patterns, so I put an Adapter pattern
in our Adapter pattern so you can adapt while you adapt.
I didn't actually hit this bug, but someone else might.
We don't actually use the context here, it's just a shim
There's a bit of refactoring here from when I was trying to log
performance more cleanly to diagnose the problem, and then there's a
reordering of regex tests that speeds up the code 500% for me.

It turns out that the std::regex library is really slow, and is going to
stay slow until they decide to break ABI compatibility.  I don't want to
rewrite those entry tests without regex and I don't want to bring in
Google's RE library or even boost::regex, so this is the best we can do
for now.
This gets us another factor of 2.5 speed improvement, so we're now about
15x faster than the original read_matlab() in total.  That's not perfect
but it's fast enough that I don't think I'll bother to try manual
char-fiddling.
@jwpeterson
Copy link
Copy Markdown
Member

The "Test with threads" error here seems to be in an example unrelated to the calculator app:

***************************************************************
* Running Example vector_fe_ex6:
*  mpiexec -np 2 ./example-opt dim=2 element_type=TRI6 boundary_condition=neumann 
***************************************************************
 
 Mesh Information:
  elem_dimensions()={2}
  elem_default_orders()={2}
  supported_nodal_order()=2
  spatial_dimension()=2
  n_nodes()=961
    n_local_nodes()=496
  n_elem()=450
    n_local_elem()=225
    n_active_elem()=450
  n_subdomains()=1
  n_elemsets()=0
  n_partitions()=2
  n_processors()=2
  n_threads()=1
  processor_id()=0
  is_prepared()=true
  is_replicated()=true

 EquationSystems
  n_systems()=1
   System #0, "DivGrad"
    Type "LinearImplicit"
    Variables="u" "p" "l" 
    Finite Element Types="RAVIART_THOMAS" "MONOMIAL" "SCALAR" 
    Approximation Orders="FIRST" "CONSTANT" "FIRST" 
    n_dofs()=1156
    n_local_dofs()=585
    max(n_local_dofs())=585
    n_constrained_dofs()=0
    n_local_constrained_dofs()=0
    max(local unconstrained dofs)=585
    n_vectors()=1
    n_matrices()=1
    DofMap Sparsity
      Average  On-Processor Bandwidth <= 6.57439
      Average Off-Processor Bandwidth <= 1.09516
      Maximum  On-Processor Bandwidth <= 571
      Maximum Off-Processor Bandwidth <= 585
    DofMap Constraints
      Number of DoF Constraints = 0

libMesh terminatinglibMesh terminating:
ERROR: Bad FEType.family= RAVIART_THOMAS
[0] ../src/fe/fe_abstract.C, line 144, compiled Dec  2 2024 at 10:11:05

:
ERROR: Bad FEType.family= RAVIART_THOMAS
[1] ../src/fe/fe_abstract.C, line 144, compiled Dec  2 2024 at 10:11:05

@jwpeterson
Copy link
Copy Markdown
Member

The "Test complex" failure seems to be an actual issue with std::complex and not just a -Werror issue:

./include/libmesh/fdm_gradient.h: In instantiation of 'GradType libMesh::FDMGradient<GradType>::operator()(const libMesh::FEMContext&, const libMesh::Point&, libMesh::Real) [with GradType = libMesh::VectorValue<std::complex<double> >; libMesh::Real = double]':
../src/apps/L2system.C:140:45:   required from here
./include/libmesh/fdm_gradient.h:55:43: error: no match for 'operator/' (operand types are 'std::complex<double>' and 'int')
   54 |     g(0) = (val(c, p+Point(_eps), time) -
      |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
   55 |             val(c, p+Point(-_eps), time)) /
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
   56 |            2 / _eps;
      |            ~                               

We were hitting this case with adaptivity_ex4 in our "zero_sol" code,
and though that's probably not a great way for that example to calculate
norms it's also not something we want to break, especially because the
same bug might affect the fine-system code path too.
We're apparently not hitting this in our --enable-complex CI?
Even if we can't use these dimensions later, FEMContext still wants to
build them if it sees a variable of those types, just in case it hits an
Elem of those dimensions.
This must have been copied and pasted from earlier harder-to-solve
examples; we're not pushing our own solver options here that need to not
be overridden.
@moosebuild
Copy link
Copy Markdown

Job Coverage, step Generate coverage on 130f9c2 wanted to post the following:

Coverage

201eb6 #4027 130f9c
Total Total +/- New
Rate 62.33% 62.30% -0.02% 28.77%
Hits 72660 72716 +56 42
Misses 43916 43995 +79 104

Diff coverage report

Full coverage report

Warnings

  • New new line coverage rate 28.77% is less than the suggested 90.0%

This comment will be updated on new commits.

@roystgnr roystgnr merged commit 7931e5b into libMesh:devel Dec 12, 2024
@roystgnr roystgnr deleted the calculator_error branch December 12, 2024 23:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants