 |
v0.8.20
|
|
v0.8.20
|
If you write a paper using results obtained with the help of MoFEM, please cite one or more of the following references:
Version 0.5.42 cite as
DOI:
L. Kaczmarczyk, Z. Ullah, K. Lewandowski, Xuan Meng, Xiao-Yi Zhou, C. Pearce. (2017). MoFEM-v0.5.42 [Data set]. Zenodo. http://doi.org/10.5281/zenodo.438712
Each user module can have own DOI and reference. All module references supplements MoFEM reference. For example homogenisation module DOI as follows
The current MoFEM version can be identified by Semantic Versioning and Git Commit Id. Git Commit Id is unique and points to particular code commit. Semantic Versioning is not unique, more than one commits to git repository can have the same version.
First two lines of every executed code which is build with MoFEM library look like that
That allows to identify git commit id and human readable MoFEM version.
MoFEM is developed continuously (see How MoFEM is developed?) and any commit which introducing changes that directly have an impact on users modules implementation should result in increment build version. For example if new functionality is added, name of interface function changed or some function deprecated etc. that will result in incremented build version. Note that each users module has set minimal MoFEM version to which is compatible, see How to add user module? for details.
On the other hand changes/improvements to core library like modification of local variable name or when local documentation added, that will result in new commit however will NOT result in new build version, since implementation of users modules is not influenced by changes in main library.
Build version is in range from 0-100, at the end of the range minor version should be automatically incremented. Minor version is in the range from 0-10, at the end of the range major version should be automatically incremented. The minor or major version could be changed at any time when major/minor feature is initiated.
In addition to above rules, the general principles could apply, in short,
The MoFEM version can be set in CMakeList.txt located in root source directory, in lines
MoFEM is developed continuously, i.e. any merged pull request to the CDashTesting branch triggers automatic testing on the development server. The code is verified during when a pull request is accepted and merged and validated when the test on the development server are passed. If tests are passed CDashBranch is merged to master branch.
If problem is large, mesh can be partitioned for to save memory and improve efficiency. This can be done using native MoFEM tool,
The partitioned mesh is saved to file out.h5m in current working directory.
For large meshes, partitioning can be in parallel, for example
Code is run using direct solver, i.e. MUMPS on coarse level. Note that loaded mesh is portioned and each processor only reads part of the mesh, i.e. -my_is_partitioned.
When making changes in a users_modules, a git submodule, the main git repo will register a version change. For example:
The commi t ID of the submodule is used to track which version to pull when pulling the main repo. Updating to the latest commit will then pull the your latest changes.
Look to Valgrind documentation. However, a quick answer is
Valgrind comes with a tool for measuring memory usage: massif. Example usage:
This generates massif.out files that can be visualised with a graph using ms_print.
To profile code in MacOS X environment, from line command you execute instruments, for example
This generates directory instrumentscli0.trace and for next run instrumentscli1.trace, and similarly for subsequent runs. You can see changes in execution of the code by
If you use Linux you can alternatively use Valgrind, see How to profile code with Valgrind?.
See PETSc documentation http://www.mcs.anl.gov/petsc/petsc-current/docs/manualpages/Profiling/PetscLogStageRegister.html and examples http://www.mcs.anl.gov/petsc/petsc-current/src/ksp/ksp/examples/tutorials/ex9.c.html
PETSC is capable of timing events and displaying their collective output. To create a new event requires registering the event and add this to run time commands:
Example output:
You have to install Valgrind http://valgrind.org and graphic user interface KCachegrind http://kcachegrind.sourceforge.net/html/Home.html. If you using Linux, for example ubuntu you can do that executing following commands,
If you using OS X you can use Homebrew http://brew.sh to make installation,
If you have packages installed, follow instruction from http://kcachegrind.sourceforge.net/html/Documentation.html
MoFEM is a core library providing functionality for implementation of user modules where applications for particular finite elements or problems are implemented. User module is an independent repository, private or public and independently managed by its owner.
User module is added to the project by cloning repository into directory $HOME/mofem-cephas/mofem/users_modules, for example, module for computational homogenisation has repository in Bitbucket and can be added by
Sometimes users modules depend on other modules, in that case, homogenisation module uses some old obsolete classes (which should not be used in new developments), thus in this particular case addition you have to clone also obsolete module
Once the module is added, you have to go main build directory where users modules are located and rebuild the code. So you have to do
Note the first command is used to trigger reconfiguration of users modules with the new module.
Note, each user module consist InstalledAddModule.cmake, with beginning lines,
In that file minimal version of the core library is given (e.g. v0.5.63). Thus if you have too old version of core lib, it won't be added and cmake will generate an error. In that case, you need to update core library by pulling most recent version from Bitbucket repository and install core library.
User module can be independent repository, private or public and independently managed and owned form MoFEM library. If user module is part of MoFEM repository can be simply added by adding it to ModulesLists.cmake in users modules directory. However is recommended that user module is project/respository by its own, repository should be cloned to users modules directory, f.e. in mofem-cephas/mofem/users_modules
In user module directory directory should be file file, InstalledAddModule.cmake, with content,
You can use gdb inside docker, remembering to set cmake with debugging build type, for example
It is one non trivial trick that you have to do, to make debugging possible in docker, you need to run docker container in privileged mode, for example
In cubit you need to generate 10 node tetrahedral. You simply create block and set element type to TETRA10, as follows
In the code, you need to create field to keep geometry
Next set order of approximation field. If you have 10 node tetrahedrons, you need to have at least 2nd order polynomials to approximate geometry;
The last step is to prject information from 10 node terahedrons on hierarchical approximation field, as follows
Look at examples of use to user modules, for example elasticity.cpp.
In you library directory execute
This create directory html. Open file html/index.html to see results in your browser.
Basic support for C/C++ languages is provided with Microsoft C/C++ extension. To configure IntelliSense code-completion tool add -DCMAKE_EXPORT_COMPILE_COMMANDS=ON to users_modules's cmake command. This will generate compile_commands.json file which has to be added to .vscode/c_cpp_properties.json file located in the working project. Example c_cpp_properties configuration on Mac should look like follows:
For debugging on Mac the most commonly used extension is CodeLLDB plugin. The configuration is straightforward: choose lldb type, set the path to the executable (compiled with debug flag!) as program, arguments for the command line put in args. Optionally, the path to current working directory can be set (cwd). Example configuration for fracture module is presented below.
In command line put
Or you can do that in the code
When debugging a nonlinear problem, it might be useful to test the jacobian matrix. The command below will print 'Explicit preconditioning Jacobian', 'Finite difference Jacobian' and the most useful 'User-provided matrix minus finite difference Jacobian'.
To view those matrices in a graphical form, simply add:
This will create a folder named Draw_0x7f86644**** with 3 image files: user-jacobian (0), finite difference jacobian (1) and the difference (2). The draw function works only with one processor.
