matmechlab / asfem Goto Github PK

The msh4 file generated by examples/pffracture/logo.geo can not be well recognized once the mesh is extremely fine(msh file size>=15Mb), the following error can be captured:

******************************************************************************
*** Error:i=0 is out of range(256876) for your vector                  !!! ***
******************************************************************************
******************************************************************************
*** AsFem exit due to some errors                                      !!! ***
******************************************************************************

However, the same geo file can produce the working msh2 file for the simulation. Moreover, this issue can be resolved in msh4 importor when the mesh is coarse (~10k nodes).
The check should be executed for:

• msh4 io for large mesh case
• gmsh's msh4 output function for extremely fine mesh

We need a better solution for folder-based output, which is a very natural property in C++17. However, for some old compiler, it is not supported. We need a solution to solve this issue.

There is not very much discussion of how AsFem compares to other finite element libraries in the JOSS paper. Libraries that you could mention include:

• FEniCS: website, GitHub repos, paper
• MFEM: website, GitHub repo, paper
• deal.ii: website, GitHub repo, paper
• DUNE: website, GitHub repos, paper
• FreeFEM: website, GitHub repos

It's not fully clear to me which decisions have been made in this library to keep it "simple". Some questions you could consider to help clarify this:

• How big is the range of problems the library can solve?
• Which families of finite element basis functions does the library support? Is it lowest order Lagrange only?
• How is the user expected to interact with the library? Is this in a simpler way than other libraries?
• Which features have been left out of AsFem to keep it simple?

Compiler:GCC12.2.0
Mpi:Openmpi4.1.4
Petsc:3.18.0
System:Ubuntu

Running asfem binary program can see this warning.

--------------------------------------------------------------------------
By default, for Open MPI 4.0 and later, infiniband ports on a device
are not used by default.  The intent is to use UCX for these devices.
You can override this policy by setting the btl_openib_allow_ib MCA parameter
to true.

  Local host:              ln0
  Local adapter:           mlx5_0
  Local port:              1

--------------------------------------------------------------------------
--------------------------------------------------------------------------
WARNING: There was an error initializing an OpenFabrics device.

  Local host:   ln0
  Local device: mlx5_0
--------------------------------------------------------------------------

This issues may be solved by this url open-mpi/ompi#10841.

Thank you very much for your open source. It would be even better to output the results in a folder.

It is necessary to add the Node-Set information in the Mesh class. In this scenario, users can apply the nodal type boundary condition, i.e. the nodal force or the nodal flux or the nodal type Dirichlet boundary condition.

Its time to split the boundary conditions into: nodal type (boundary nodes) and elemental type (boundary elements). Therefore, the postprocess class should also depend on both the nodal and elemental information.

So, we should allow the storage of both the Node-set information and Element-set information in our Mesh class.

Some of the link information is outdated, the website needs to be updated.

The Gmsh2IO mesh reader is not working well and should be updated. The physical group data should be clearly marked out, as well as the bulk mesh information.

The R abs tol and R rel tol are not well taken into consideration by PETSc's TS (time-stepping). It will always utilize the PETSc-determined default parameters.

Therefore, it's necessary to have a new time-stepping from AsFem itself.

We could create a new TS by combining the TS from PETSc and the one implemented in AsFem.

The values along the Z-axis are essentially a simple extension of the 2D case when utilizing PETSc's random number generator.
Instead of 2D random cases, it should be "real" random values!

We could use, either the random number generator from PETSc or the one from ctime standard library.

When compiling with gcc11.2.0, the following error occurs:

In file included from /home/by/Projects/GitHub/AsFem/external/eigen/Eigen/Core:330,
                 from /home/by/Projects/GitHub/AsFem/external/eigen/Eigen/Dense:1,
                 from /home/by/Projects/GitHub/AsFem/external/eigen/Eigen/Eigen:1,
                 from /home/by/Projects/GitHub/AsFem/src/Utils/MathUtils/RankTwoTensor.cpp:17:
/home/by/Projects/GitHub/AsFem/external/eigen/Eigen/src/Core/products/TriangularMatrixVector.h: In static member function ‘static void Eigen::internal::trmv_selector<Mode, 1>::run(const Lhs&, const Rhs&, Dest&, const typename Dest::Scalar&) [with Lhs = Eigen::Transpose<const Eigen::Block<const Eigen::Block<Eigen::Matrix<double, 3, 3>, -1, -1, false>, -1, -1, false> >; Rhs = Eigen::Transpose<const Eigen::CwiseBinaryOp<Eigen::internal::scalar_product_op<double, double>, const Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<double>, const Eigen::Matrix<double, 1, -1, 1, 1, 3> >, const Eigen::Transpose<const Eigen::Block<const Eigen::Block<const Eigen::Block<Eigen::Matrix<double, 3, 3>, -1, -1, false>, -1, 1, true>, -1, 1, false> > > >; Dest = Eigen::Transpose<Eigen::Block<Eigen::Block<Eigen::Matrix<double, -1, -1, 1, -1, -1>, 1, -1, true>, 1, -1, false> >; int Mode = 6]’:
/home/by/Projects/GitHub/AsFem/external/eigen/Eigen/src/Core/products/TriangularMatrixVector.h:332:12: error: ‘result’ may be used uninitialized [-Werror=maybe-uninitialized]
  327 |     internal::triangular_matrix_vector_product
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  328 |       <Index,Mode,
      |       ~~~~~~~~~~~~
  329 |        LhsScalar, LhsBlasTraits::NeedToConjugate,
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  330 |        RhsScalar, RhsBlasTraits::NeedToConjugate,
      |        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  331 |        RowMajor>
      |        ~~~~~~~~~
  332 |       ::run(actualLhs.rows(),actualLhs.cols(),
      |       ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  333 |             actualLhs.data(),actualLhs.outerStride(),
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  334 |             actualRhsPtr,1,
      |             ~~~~~~~~~~~~~~~
  335 |             dest.data(),dest.innerStride(),
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  336 |             actualAlpha);
      |             ~~~~~~~~~~~~
/home/by/Projects/GitHub/AsFem/external/eigen/Eigen/src/Core/products/TriangularMatrixVector.h:105:24: note: by argument 5 of type ‘const double*’ to ‘static void Eigen::internal::triangular_matrix_vector_product<Index, Mode, LhsScalar, ConjLhs, RhsScalar, ConjRhs, 1, Version>::run(Index, Index, const LhsScalar*, Index, const RhsScalar*, Index, Eigen::internal::triangular_matrix_vector_product<Index, Mode, LhsScalar, ConjLhs, RhsScalar, ConjRhs, 1, Version>::ResScalar*, Index, const ResScalar&) [with Index = long int; int Mode = 6; LhsScalar = double; bool ConjLhs = false; RhsScalar = double; bool ConjRhs = false; int Version = 0]’ declared here
  105 | EIGEN_DONT_INLINE void triangular_matrix_vector_product<Index,Mode,LhsScalar,ConjLhs,RhsScalar,ConjRhs,RowMajor,Version>
      |                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[ 14%] Building CXX object CMakeFiles/asfem.dir/src/InputSystem/PostprocessBlockReader.cpp.o

The auto test scripts should be developed for different toolkits, for instance:

• gcc/openmpi
• gcc/mpich
• clang/openmpi
• clang/mpich
• oneAPI

In line 47 of file AsFem\include\Mesh\AnaqusIO.h, the defined getfun should be GetSubElmtDimFromInp() rather than GetSubElmtDimFromGmshInp(), since this is AbaqusIO importer definition.

For HPC system, the number of cpu cores is required to check the srun command works or not for slurm job system.

The APIs for "Elst" and "Nset" should be well defined in Abaqus IO. Both the "Elst" block and "Nset" block should be put into two different mesh information set.

*Elst ---> for element set information
...

which should be used for elemental type boundary conditions.

*Nset---> for node set information
...

this should be used for nodal type boundary conditions.

New Abaqus IO should distinguish these different information sets.

The *.inp file import function is required in the [mesh] block.

Its time to design a more flexible mesh importer for different kinds of mesh, i.e. inp, msh and msh4 file format.

To this end, Mesh inherited from AbaqusIO, GmshIO, NetgenIO or whatever users required could be the final solution.

Some input files of mechanics failed during the tests, we need some repairing work for them.

Dear Professor BaiYang
Thanks for your advice to help me to compile AsFem on Oct.25th,2022. At the beginning of compiling AsFem, I made a mistake: I could not notice this environment variable of MPI_DIR. In fact, I first use the TianHe supercomputer, it was too different. There are a lot of differences and restrictions that supercomputers compare PC.they ban user's root access, Restrict direct Internet access, etc. From the National Supercomputing Tianjin Center document, I imported two different MPI in the process. One is openmpi, another is mpich. This is what causes errors later in the compilation, then the PETSc and AsFem 's compiling gets out of hand.
Now There was an error which "can not find msh mesh file in your 'file=' option of the [mesh] block, please check your input file" when I tried to use slurm for parallel processing. After that, I was repeatedly checking the I/O permissions of these files which are under the current work location, and the files whether existed. On the one hand, I promise that the command "chmod 777 -R ." was used. On the other hand, they indeed exist. Maybe have the other causing the reason for the error. But this error still appears. If I have enough time, I will see AsFem's source code whether may have questions.
My English writing ability is limited, if there is no the authentic place, please understand.
Thank you again for your help. I wish you all the best.

Yours sincerely
Wwj

It can be extremely useful to implement a transformation class for the calculation between different systems, i.e., the cartesian coordinate to the spherical coordinate system, three-dimensional system to the pseudo-2D system, and so on.

In the 3D scenario, a correct expression for the 2D shape funs' derivative is necessary. For the curved surface in the 3D case with the gradient in the Z-direction, the current code may fail!

The following one may fail for gradu_z in 3D case:

_DetJac=(_dydxi*_dzdeta-_dydeta*_dzdxi)*(_dydxi*_dzdeta-_dydeta*_dzdxi)
           +(_dzdxi*_dxdeta-_dzdeta*_dxdxi)*(_dzdxi*_dxdeta-_dzdeta*_dxdxi)
           +(_dxdxi*_dydeta-_dxdeta*_dydxi)*(_dxdxi*_dydeta-_dxdeta*_dydxi);
    _DetJac=sqrt(_DetJac);

    if(abs(_DetJac)<1.0e-15){
        MessagePrinter::PrintErrorTxt("singular element in 2D case, this error occurs in your 2D shape function calculation");
        MessagePrinter::AsFem_Exit();
    }

    

    _Jac[0][0]= _dxdxi;_Jac[0][1]= _dydxi;
    _Jac[1][0]=_dxdeta;_Jac[1][1]=_dydeta;

    _XJac[0][0]= _Jac[1][1]/_DetJac;
    _XJac[0][1]=-_Jac[0][1]/_DetJac;
    _XJac[1][0]=-_Jac[1][0]/_DetJac;
    _XJac[1][1]= _Jac[0][0]/_DetJac;

    double temp;
    for(int i=1;i<=GetShapeFunNums();i++){
        if(flag){
            temp=(*this)(i,1)*_XJac[0][0]+(*this)(i,2)*_XJac[0][1];
            (*this)(i,2)=(*this)(i,1)*_XJac[1][0]+(*this)(i,2)*_XJac[1][1];
            (*this)(i,1)=temp;
        }
       _shape_value[i-1]=(*this)(i,0);
       _shape_grad[i-1].setZero();
       _shape_grad[i-1](1)=(*this)(i,1);
       _shape_grad[i-1](2)=(*this)(i,2);
    }

In both plane strain and plane stress, there exist certain tensor expressions that are currently inconsistent and need to be corrected for the 2D linear elastic problem

Issues:

• Consistent formula for plane strain
• Consistent formula for plane stress

random() function is not working in VS2019

While performing the review for the JOSS paper submission, I started down the path of installing AsFEM on osx. There are several comments from this experiment.

1. If OSX is not supported, mention it explicitly in the documentation. You should list the platforms that are supported clearly and what compilers you expect the build to work without any user tweaks.
2. -fopenmp is enabled by default and added to the build flags. This is unacceptable. This should be exposed as a user configurable option and the actual flag should depend on the compiler being used for the build.
3. On OSX, the library is explicitly trying to link with libpetsc.so since this is hardcoded in the configure CMakeLists.txt. What happens when PETSc is configured as a static library only? How about a shared library in OSX that generates libpetsc.dylib?
4. How do I run the tests when configuring out-of-source? This is the standard approach for CMake builds and ctest or make test does not produce any output. I haven't yet re-run in-source as I usually do not prefer this mode. However, if this is the recommended approach for AsFEM, please state this in the documentation.

When users try to give the input file name from the terminal, it seems AsFem can not well recognize the file name.

All the shape fun classes should offer the illustration of the node ordering, and make them consistent with the VTK cell. All the sub shape fun classes should use the same node ordering as the VTK cell.

Checklist:

• Edges in 1D
• Quad4 in 2D case
• Quad8 in 2D case
• Quad9 in 2D case
• Tri3 in 2D case
• Tri6 in 2D case
• Hex8 in 3D case
• Hex20 in 3D case
• Hex27 in 3D case
• Tet4 in 3D case
• Tet10 in 3D case

In line 168 of the file AsFem/include/Utils/MatrixXd.h, there is a typing error, it should be ' * ' rather than '+'.
`
//*** for *

inline MatrixXd operator*(const double &val)const{

    MatrixXd temp(_M,_N);

    for(int i=0;i<_MN;++i) temp._vals[i]=_vals[i]+val;

    return temp;

}

`

The line should be
for(int i=0;i<_MN;++i) temp._vals[i]=_vals[i]*val;

Instead of running the simulation immediately, we need args from the command line to allow users to read their input file only. Thus, we can verify the input data easily.

Installing the requirements of AsFem (Petsc, etc) can take a while. It would nice for new users is there was a Docker image or some other similar package that could be downloaded to use the library without having to build everything from source

Every time, I have to save the mesh file from netgen as xxx.gmsh2 (in the old version, it is xxx.msh), then re-mesh it in gmsh due to the different node index order between these two packages (Why???).

Now, the ticket is open for this purpose, we should support the gmsh2 file directly without more 'mesh' steps.

When AsFem reads the msh file generated by neper, the surface and volume mesh may not be correctly identified. To resolve this problem, more experiments, both 2D and 3D, are required.

The source term is required in the Cahn-Hilliard equation to automatically generate/degenerate the species due to the chemical reaction.

Thereby, the current version needs some improvements to account for the source term. Moreover, we should allow users to select the free energy expressions they like, not only be restricted to the binary-mixture cases, i.e. (c-ca)^2*(c-c^b)^2, the polynomial cases.

This should also become a good "Example" to demonstrate the phase-field modeling ability of AsFem.

Let's do it!

The installation - even when considered together with the installation instructions - is not very comfortable.

I managed to install AsFem after several attempts on my arch-based linux, but I did not like that I had to fix/correct several parts of the installation due to several implicit assumptions used that should be made explicit.
A few points:

• In the instructions a debian-based OS is assumed (see the prequisite packages and apt install ... instructions). I think restricting to debian-based systems is OK, but please add sentences that other OS-users will need to adapt...
• Several things are hardcoded in the cmake-build-files. I suggest to use the full power of cmake. cmake has variables that can be used to let cmake search for directories for dependecies (PetSC / MPI / ..). Global environment variables don't need to be used here. Currently global environment variables shall be used to described dependencies. I suggest to a) replace these with cmake-variables and b) to check for the existence of the correspondingly needed libraries in the corresponding location before starting the build process.
• A full setup script could also be provided, e.g. similar to the github-workflow-file.
• if a Docker-Setup is set up, see #62 I would also recommend to publish the full Docker-file as it is also a documentation of the required dependencies and the setup.

We need a benchmark toy model for 1d plasticity problem

There's currently no reference for the finite element method itself (eg Ciarlet's book)

The oscillation is observed in the triangle-6 node mesh, where the second order shape function and related gauss point integration rule are involved, the result looks like below:

The possible reason could be the generation of the guass point. Thereby for this case, it should be improved definitely!

An additional option to choose a linear equation solver, i.e. mumps, superlu_dist, and so on is required. From this point on, the petsc itself should contain all of these solvers.

This error's reason is not include .
Then I add:
#include <vector>
The compile is OK!

It's time to implement the restart/recover functions for long-time simulation.

The restart file is required for such a purpose, which should contain:

• solutions of current and previous steps
• velocity, acceleration information to recover the simulation
• (history)material quantities for the recovery
• log file system to track the status of the whole simulation process

A new reaction force or uniaxial stress-strain curve plot post-processor is required. This should be added to our examples for Miehe's paper as a solid benchmark test.

It would help to add support for contact formulations.

According to some internet connection problems, the installation for the external packages, i.e. mumps or superlu_dist may become extremely slow in some cases. Therefore, we need an automatic detecter for the default solver.

The solution should be:

if(mumps_is_installed)
  solver=mumps
else
  solver=gmres
end

Compiler:MSVC;
OS:Windows 10;
Thanks for the issue raised by "Qingchen", and I am "Jie" in this QQ group(879908352).
In the Vector3d Class which is declared in this path "include/Utils/Vector3d.h", the norm function throw a exception which is a Floating-point underflow. It may a undefine behavior due to use different compilers.
AsFEM is large .So I will only add some useful modify to Vector3d.

When I try to compile AsFem in Windows, the VS always tell me the vector3d's right-hand side operator is defined multiple time. However, in Linux, the GCC just passes all the compilation without any complaint. We should fix it!

in Vector3d.cpp we have:

Vector3d operator*(const double &val,const Vector3d &a){
    Vector3d temp(0.0);
    temp._vals[0]=a._vals[0]*val;
    temp._vals[1]=a._vals[1]*val;
    temp._vals[2]=a._vals[2]*val;
    return temp;
}

in MathUtils.h, we have:

inline Vector3d operator*(const double &a,const Vector3d &b){
    Vector3d temp;
    temp(1)=a*b(1);temp(2)=a*b(2);temp(3)=a*b(3);
    return temp;
}

this is quite stupid mistakes.

By the way, for the later release. The source code should be compiled in both the Linux system and windows system to ensure everything is ok in AsFem.

The gpProj vector in the Elmt class is incorrectly assembled; it should be node independent. An additional function to save the global residual array should be implemented for the reaction force.

For instance,

[elmta]
  [test]
    type=mechanics
    save_residual=true
   [end]
[end]

The projection should still be responsible for projecting the quantities from gauss point to nodal points.

Tasks for this issue:

• fix gpProj assemble error
• functions for saving and accessing global/local residual vector
• re-design the sub-elmt class

Currently, only ASCII based output is available, we need also the binary format output in all the format, i.e. vtu, vtk, and csv.

The postprocess for nodal material properties is required.

The nodal type postprocess for material peroperties should contain:

• scalar material output based on node id
• vector material output based on node id
• rank-2 tensor material output based on node id(voigt or 9-components?)

error: 'MeshGenerator::generateMesh' hides overloaded virtual functions [-Werror,-Woverloaded-virtual]
error: 'QPoint::generateQPoints' hides overloaded virtual functions [-Werror,-Woverloaded-virtual]

this error occur in this classes.
MeshGenerator
QPoint