ucl / dxss Goto Github PK

(Py)-Pardiso is hard to install on newer mac hardware (since they are custom ARM M1/M2 chips). Pardiso depends on MKL which is quite hard to install on a macOS.

Hence, for a large problem, we could try an alternative solver such as MUMPS.

Expect a damped sine wave. Should do a stupid regression test of these values.

Make Janosch's existing code pulled in as part of #4 importable as a Python package

Report the test coverage of our existing tests (possibly we could go for codecov.io which is my personal favourite) and if it's very low create further issues targetted at improving coverage. At least for core functionality.

Blocked by

• #7
• #9

space_time.py contains a very big class with a long parameter list.

This needs some work to identify of data clumps and subclasses. Potentially guided by the design decisions in #40. At the very least we can group up into parameter objects and some pairings are obvious...

class Tolerance(NamedTuple):
    rel: float = 0.0
    abs: float = 0.0

for example.

• Abstract the DRY violations in solve_*d.py into _solving.py (name TBC).
• Make a de-duplication pass of Janosch's test scripts (possible overlap in scope of issue #9).

Currently we're constraining to sphinx<7 which I think is when I originally set up with sphinx-rtd-theme that theme didn't have Sphinx 7 support, but now we're no longer using that theme (and sphinx-rtd-theme also now supports Sphinx 7 anyway), so we should probably just remove the constraint.

[Also a bit of a test that I can add you all as assignees and you can see items on the project board... you can all read this?]

We should come up with a nice name for our "slab solver" deliverable but one that is precise and encapsulates the generality.

Noticed by @krishnakumarg1984 and I whilst we were pair developing.

The linting (PR #17) has broken the solve_*d.py script.

The AttributeError is reproducible on CI.

To reproduce locally

python src/dxss/solve_1d.py

at 69b68ed.

Because the ARC cookiecutter doesn't have FEniCSx nor sphinx docs building.

Separating this out from #13

Many undocumented functions but should come in its own PR. Presumably better for them to be written by Krishna or Janosch and reviewed by the other. (I could write docs but probably I'll introduce wrong statements.)

Create a contribution guide. (And force squash-merge-only in the settings).

• PR merge strategy (I'm ok with the reviewer merging when happy).
• Pass all tests? Coverage shouldn't go down (at least stays the same).
• Only allow squash merge in settings.
• Reduce codecov check precision.
• Type hints in code, not docstrings. Matt recommends Google style, so probably go with that.

We didn't realise but some of the code is taken from ngsolve which is GPL2.

So we'll need to:

1. Make dxss GPL license.
2. Or remove the code and keep MIT.

After some discussion, we seem to gravitate towards 2. It's probably the best option for future software reusability and FAIR4SW.

I've...

• Made the repo private (because we're currently caught by GPL and not distributing the GPL license).
• Investigated purging from history, which would work 👍.

Noticed while reviewing #56 that the snippet

is repeated a few different times and looks like it is doing a relatively self-contained operation of filtering set of points data before converting to NumPy array so probably worth refactoring in to a function. I think it might also be possible to avoid the loop comprehension by doing the filtering with NumPy indexing.

For the CI that runs on every push or PR, we can go with a very coarse mesh and suitable order ratio.

• Aim for convergence tests.

Hi,
I am observing segfaults when running dxss/src/dxss/solve_1d.py . The error message is as follows

~/projects/dxss/src/dxss$ python3 solve_1d.py 
KSP Object: 1 MPI process
  type: gmres
    restart=1000, using Modified Gram-Schmidt Orthogonalization
    happy breakdown tolerance 1e-30
  maximum iterations=100000, initial guess is zero
  tolerances:  relative=1e-07, absolute=1e-07, divergence=10000.
  left preconditioning
  using DEFAULT norm type for convergence test
PC Object: 1 MPI process
  type: python
    Python: dxss.gmres.PreTimeMarchingImproved
  linear system matrix = precond matrix:
  Mat Object: 1 MPI process
    type: python
    rows=41216, cols=41216
        Python: dxss.space_time.FMatrix
GMRes iteration   0, residual = 4.46e-16
The convergence reason code is 3
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range
[0]PETSC ERROR: Try option -start_in_debugger or -on_error_attach_debugger
[0]PETSC ERROR: or see https://petsc.org/release/faq/#valgrind and https://petsc.org/release/faq/
[0]PETSC ERROR: configure using --with-debugging=yes, recompile, link, and run 
[0]PETSC ERROR: to get more information on the crash.
[0]PETSC ERROR: Run with -malloc_debug to check if memory corruption is causing the crash.
Abort(59) on node 0 (rank 0 in comm 0): application called MPI_Abort(MPI_COMM_WORLD, 59) - process 

I am running the code in a fresh conda environment created as follows:

conda activate fenicsx-env
conda install numpy scipy matplotlib sympy pytest
conda install conda-forge::meshio pypardiso gmsh python-gmsh
conda install -c conda-forge fenics-dolfinx==0.7.3 mpich pyvista

And then I install dxh and dxss with pip install -e ..
Can anyone of you reproduce the error, or is this related to my machine?
I think that the error is related to the GMRes solver from PETSc, because when I run my old code in this environment which uses NGSolve's GMRes it works just fine.

In my local experiments (whilst #7 is still in review):

• Renaming the test scripts to tests/test_slab_solver_3d.py,
• and running with reduced ref_lvl (and lowering the order) works!

So the first part of this issue is rather straightforward.

They should be refactored into shorter functions ideally. Although pytest just executes the scripts, so they are de-facto end-to-end tests.

In solve_*d.py we have a wrapper class for a pardiso solver. Want to understand why we don't simply use an instance of the pardiso solver directly.

Our solve method seems to overlap with the upstream class implementation.

class PySolver:
    def __init__(self, Asp, psolver):  # noqa: N803 | convention Ax = b
        self.Asp = Asp
        self.solver = psolver
        if not pypardiso:
            warnings.warn(
                "Initialising a PySolver, but PyPardiso is not available.",
                stacklevel=2,
            )

    def solve(self, b_inp, x_out):
        self.solver.check_A(self.Asp)
        b = self.solver._check_b(self.Asp, b_inp.array)  # noqa: SLF001, TODO: fix this.
        self.solver.set_phase(33)
        x_out.array[:] = self.solver._call_pardiso(self.Asp, b)[:]  # noqa: SLF001, TODO: fix this.

Possibilities that seem sane to us:

• Strategy pattern.
• Factory pattern.
• (MVC...? I'm less convinced of this).

Blocked by

• #39

Potential subtasks

• #41
• #42

Important things to consider:

• Janosch's commit history?
  - squash commit with him as an author?
• Explain to him that we want to open the source code under (MIT || BSD-3) license. Make sure he is OK with this.
  - choosealicense.com

Other possibilities:

1. Plonk the whole thing public,
2. do a private rip-up and clean-up before making it public,
3. or reimplement bit by bit.

The dxss project requires an unreleased version of dolfinx from a specific commit from upstream's main branch.

One approach to do this would be to install the specific development version via the spack package manager. We tried this out in a personal public repository, which was unsuccessful due to difficulties in making the CMake build system discover the dependencies such as basix.

After a number of experimental trials, we decided to adopt a custom container-based build environment for the CI. This is addressed in PR #28.

It would however be useful to return to this issue in the future and investigate further, since the container-based build is restricted to only Ubuntu 22.04 presently.

Making this a full issue to track some stylistic refactoring.

• black can autoformat ✅
• ruff throws up ~500 style errors that it can't fix
  • decide whether or not to convert to CamelCaseClasses and snake_case_members
  • if not: configure ruff to ignore.

• mypy throwing around 12 errors which we probably do want to fix.

Following discussion in meeting 2023-09-21 looking at, for example,