sblauth / cashocs Goto Github PK

Add Topology Optimization Algorithms and Problem classes (with levelset functions) to cashocs for v2.0

In the documentation, the default value for newton_damped is True, but it is set to False in cashocs.io.config.py

Constrained problems do print their progress only in the console - it would be beneficial if they would also have the possibility to print to file. This could be done using the same parameters as for usual optimization problems.

The coloring for the logs is fine when considered in a terminal, but when logging to a file, makes things hard to read.
Try disabling the coloring for file output.

Run the nightly tests in mpi, too.

Supplying ksp options via a list can be very tedious and error prone, therefore, a custom class for these options should be created.

This feature is not so obvious at the moment - so a bit of documentation can help.
Also think of ways to rename the functions, because the names under which states, adjoints, gradients are to query is not obvious.

Docker images build fails when calling conda clean -tipsy.
Apparently, this is related to conda v22.11.1 which is now the latest image on dockerhub.
Possible workaround: use conda clean --all or similar

Is your feature request related to a problem? Please describe.
cashocs may use a lot of memory when either the systems are large or the geometry is large. Especially the matrices that have to be assembled use up a lot of memory, which could be used otherwise. They are kept in memory in order to speed up the assembly (which makes sense for small to medium problems).

Describe the solution you'd like
The system matrices could be reinitiated to clear memory in case a large problem is considered. Therefore, one should either check current memory status (might be difficult) or check the number of DoF's and the dimension of the problem (3D is harder than 2D, usually) and add a criteria, which state when memory is important.

Implement a github actions CI workflow that checks, whether the cashocs package from conda-forge can be installed. Could be run nightly or weekly.

This completes the mesh hierarchy (2D and 3D box meshes are already available)
Should be implemented in a separate class, as the 1D case is (somewhat) special

cashocs remeshing files are not deleted in case the remeshing succeeds, but the resulting mesh is not approved due to a mesh quality which is too low.

Proposed fix: Load the remeshing files also in the import_mesh step (which is where the exception is raised) and delete the corresponding directories.

Currently, the xdmf files for visualization are not really closed properly.

Suggestion: Wrap each call of write_checkpoint in a python "with" context manager, which looks like

with XDMFFile(mpi_comm_world(), 'name.xdmf') as xdmf:
xdmf.write(mesh)

cashocs currently does not catch all exceptions related to solving a nonlinear system with a linear solver. This can be, e.g., replicated with Navier Stokes equations. cashocs should catch the exception and raise a custom one, which indicates to the user what went wrong and what they can do / try to circumvent this behavior.

Contributing guidelines state Use the same coding conventions as established in the project.
Might it be helpful to unpack this?
Or more explicitly adding flake8.

(I'm incredibly petty and get put off working with anything that isn't blacked.)

As the title says, cashocs still prints the statistics of the optimization even if a run was not successful. This should not happen.

Give cashocs-convert and cashocs.convert a flag which turns it silent, so that no messages are displayed.

Using the keyword arguments "scalar_tracking_forms" or "min_max_terms" was recently deprecated and should be removed

Try to implement the Shape Newton Method from "A Linear View on Shape Optimization" (https://arxiv.org/abs/2203.07175)

This would be a nice addition to the optimization methods already available in cashocs.

Describe the bug
When generating a surface mesh with gmsh and reading it into cashocs with cashocs-convert, a flat mesh is created instead of a manifold mesh.

Add the possibility for the BFGS iteration to be restarted, which can aid convergence for complex problems.

The curvature condition in the L-BFGS method says to discard the memory and re-start with steepest descent in case y \cdot s is not positive. To check this condition, we need a good relative (numerical) estimate, when this is "numerically close to 0". This should be further investigated.

When cashocs is verbose, the output is something like:

Iteration i --- Cost Functional value: j --- Gradient norm: z

This could be changed to an (easier to read) format

iteration cost functional gradient norm
i j k
l m n
o p q

where the title row reappears every few (10 / 20) iterations.

Is your feature request related to a problem? Please describe.

Even after #56 there still exist a number of places, where cashocs printing to the console is sub-optimal, which could be improved by the same techniques used in #56.

Describe the solution you'd like

cashocs should use shorter output messages which are better to read and understand and also fit the default terminal size.

The Armijo line search procedure can take a long amount of time to find a suitable stepsize. This can be made (somewhat) faster by automatically decreasing the stepsize when the resulting update would be "too large" - for optimal control, this is hard to check, but for shape optimization a criterion based on the size of the geometry could be easily derived.

Remeshing is not (yet) supported for constrained problems - cashocs should issue an exception if remeshing is tried within this context.

Is your feature request related to a problem? Please describe.
cashocs-convert currently is a command line only tool.

Describe the solution you'd like
It would be great to have a wrapper to use it in python

The documentation should contain examples for how to use the space mapping methods in cashocs.

One could try to implement a little more sophisticated stepsize computation, with different factors for increasing (when a step is accepted) and decreasing (when a step is rejected) the stepsize. Currently, there is only one factor.

Replace the usage of the os.path module with pathlib to handle all file / path related operations

When starting an optimization problem with a mesh below the lower mesh quality (maybe also below the higher mesh quality?), it can get stuck in an infinite loop.

cashocs cannot perform a remeshing in parallel when the mesh quality measure is chosen as radius_ratios or skewness (perhaps also others are relevant)...
Guess: The quality measure / minimum is different for each process (so a deadlock occurs)

Hello.
Cheers for this project.
A heads up on failing test.

$python -m pytest 
... 
========================================== FAILURES ==========================================
_________________________________ test_scalar_multiple_norms _________________________________

    def test_scalar_multiple_norms():
        config = cashocs.load_config(dir_path + "/config_ocp.ini")
    
        u.vector()[:] = 40
    
        J = Constant(0) * dx
        norm_y = y * y * dx
        norm_u = u * u * dx
        tracking_goals = [0.24154615814336944, 1554.0246268346273]
        J_y = {"integrand": norm_y, "tracking_goal": tracking_goals[0]}
        J_u = {"integrand": norm_u, "tracking_goal": tracking_goals[1]}
        J_scalar = [J_y, J_u]
        config.set("OptimizationRoutine", "initial_stepsize", "1e-4")
    
        test_ocp = cashocs.OptimalControlProblem(
            F, bcs, J, y, u, p, config, scalar_tracking_forms=J_scalar
        )
        test_ocp.solve(algorithm="bfgs", rtol=1e-6, max_iter=500)
    
>       assert 0.5 * pow(assemble(norm_y) - tracking_goals[0], 2) < 1e-3
E       AssertionError: assert (0.5 * 0.0057537558828288345) < 0.001
E        +  where 0.0057537558828288345 = pow((0.31739967409898506 - 0.24154615814336944), 2)
E        +    where 0.31739967409898506 = assemble(Form([Integral(Product(Coefficient(FunctionSpace(Mesh(VectorElement(FiniteElement('Lagrange', triangle, 1), dim=2), 11...agrange', triangle, 1), dim=2), 110), 'everywhere', {}, <dolfin.cpp.mesh.MeshFunctionSizet object at 0x7f5189016e70>)]))

tests/test_optimal_control.py:433: AssertionError

Possibly/ possibly not relevant : I did not use conda to install packages.

More flexibility for the user. Possible options are:

• A linearized exact line search (which would be exact for linear-quadratic problems)
• An interpolation-based line search which would generate a quadratic / cubic model of the 1D problem and search for the minimizer of the model

cashocs-convert should only require one argument, the input .msh mesh file. For input mesh.msh the default output name should be mesh.xdmf, which can be changed by the (then optional) option -o --output.

Equation (3.50) from Kelley - "Iterative Methods for Optimization" could be implemented as a guard against poor scaling for the stepsize.

Remove no longer needed classes and functions, which have been previously deprecated.

Investigate the possibility of doing projected descent algorithms for shape optimization.

When documenting a demo, this should be done directly in the source code.

This can be done using MyST syntax, and using jupytext to convert the source files to .md, which can be read by sphinx using myst-parser.

cashocs.load_config should display a warning that no config file was found (if it does not exist) and that the default config is used.

For example, it is not clear right now whether cashocs.io.convert refers to the sub-module or if it refers to the function cashocs.io.convert.convert, which is imported into cashocs.io in its init.

When trying to scale the cost functional, cashocs replaces an (input) IntegralFunctional with a ufl.Form. This should not be the case.

Basically, restarting the script has several drawbacks (including that it makes using ConstrainedProblems and Space Mapping not possible yet), so this should be avoided.

Possible idea: Users could supply a factory for the input parameters depending on the mesh, so this function can be called each time the mesh changes. The classes then have to be reinstantiated and history has to be saved / passed to the newly instantiated objects.

This would allow users to choose their own desired accuracy for the precision of the numbers which are printed

Switch to the sphinx_book_theme for cashocs documentation starting with v2.0

When cashocs does not converge (e.g. due to max amount of iterations) the stats that are printed are not consistent, i.e. the final iteration has the same values as the one before it

When using a constant function as (state) variable which should be saved to xdmf, this is currently not supported in FEniCS. Error message is along the lines of "Real element not supported".

Proposal: Catch this case and ensure that these variables are not saved for visualization.

cashocs interpolator class (cashocs._utils.Interpolator) uses a call to fenics.interpolate in case of parallel usage. This should be avoided, as the interpolator class should make use of the transfer matrix (which it does in serial) in all cases.

Describe the bug
When cashocs-convert is called with relative paths, it fails due to wrong file name extensions. This can be fixed by using rsplit('.', 1) instead of .split('.')

The polynomial based line search implemented in cashocs v1.9 (at the time of writing in development) should be default line search.
Additionally, config parameters which are now under OptimizationRoutine should be placed into LineSearch and it should be decided, if the factors or 1/factor are used in the config.