New version v0.6.1 - Error handling

[Lukasz Kaczmraczyk]

We have a new minor version of MoFEM v0.6.1. The first number is a major version, second is minor version and last (third) number is release number.

With the new minor version come some significant changes, MoFEM is working with new PETSc release v3.8.0 (fixed and tested by Karol) and has improved the system for handling errors. Old way still working, don't worry no need to change existing codes.

Error handling is critical; with it we can quickly guess what and where is a problem. This helps to develop code faster, and if someone runs into a bug or do something wrong, it is easier to give advise and help. From the other hand error handling can not compromise efficiency and should be effortless during coding.  PETSc and MoAB sets standards, we follow them,  however,  we have to handle error generated in the other codes, PETSc and MoAB functions. 

Note that other packages usually wrap the other libraries functions, handling internal errors in the wrapper. Technique of wrapping has some advantage, however, demands constant management and keeping wrappers up to date and constantly add new functionalities, taking limited time and human resources. As a policy, we do not wrap PETSc and MoAB functions, but our error handling system can handle errors emerging in functions of those libraries.

Changes:

First all MoFEM functions should return MoFEMErrorCode, and have format

MoFEMErroCode doWork() {
  MoFEMFunctionBeginHot;
  if(2+2!=4) {
   SETERRQ(PETSC_COMM_SELF,MOFEM_IMPOSIBLE_CASE,"Huston we have a problem");
  }
  MoFEMFunctionReturnHot(0);
}

Note that function start with   MoFEMFunctionBeginHot and ends with MoFEMFunctionReturnHot. Suffix Hot means that efficiency is critical, and this is recommended for short (quick) and often used functions, like in most inner loops.  For bigger functions, used in outer loops, is recommended to have

MoFEMErroCode doWork() {
  MoFEMFunctionBegin;
  // some code
  CHKERR funDoSomathig(); /// !!!! <<< LOOK HER HOW ERRROR CAN BE HANDLED
  // more code
  MoFEMFunctionReturn(0);
}

Note MoFEMFunctionBegin and MoFEMFunctionReturn. With that code if error takes place is catch better, i.e. information about trace of error is more accurate, thus use this by default. 

All functions now can be checked by

MoFEMErrorCode merr = fun_mofem(); CHKERRG(merr);
PetscErrorCode ierr = fun_petsc(); CHKERRG(ierr);
moab::ErrorCode rval = fun_moab(); CHKERRG(rval);

Note that user do not have to allocate error variables, those are globally defined in Common.hpp (http://mofem.eng.gla.ac.uk/mofem/html/_common_8hpp.html see variables at bottom of the page)

However, more significant change is that you can verify error code in shorter way,

CHKERR fun_mofem();
CHKERR fun_petsc();
CHKERR fun_moab();

The least way of error handling is compact and works well with clang-format.
 

See example 

http://mofem.eng.gla.ac.uk/mofem/html/elasticity_8cpp.html

Kind regards,

Lukasz

[ignat...@gmail.com]

Hello,

I tried to implement changes regarding error handling in my module.

All seem to work fine except for case below:

when I change the code 

ierr = PetscOptionsEnd();

CHKERRQ(ierr);

to

CHKERR PetscOptionsEnd();

I receive the error

/Users/ignathanas/mofem_installation/mofem-cephas/mofem/users_modules/basic_finite_elements/simple_elasticity/simple_elasticity.cpp:420:12: error: 

      expression is not assignable

    CHKERR PetscOptionsEnd();

    ~~~~~~~^~~~~~~~~~~~~~~~~

/Users/ignathanas/mofem_installation/petsc/include/petscoptions.h:213:38: note: expanded from macro 'PetscOptionsEnd'

#define    PetscOptionsEnd() _5_ierr = PetscOptionsEnd_Private(PetscOptionsObject);CHKERRQ(_5_ierr);}} while (0)

 when compiling.

Is there a mistake from on behalf?

Thanks in advance.

Ignatios

[Lukasz Kaczmraczyk]

Ignatios,

For this specific case pleas do

ierr = PetscOptionsEnd();
    CHKERRQ(ierr);

I am aware of this problem, and this is only exception which I know.

Lukasz

[Lukasz Kaczmraczyk]

Hey,

After many iterations, backwards and forward, I manage to create the handler which is light, i.e. has not variables on stack no arguments (except error code itself passed by overloaded operator <<) and set at compilation time. Yet, in case of the error full trace of error is printed,  for example

[0]MoFEM ERROR: --------------------- MoFEM Error Message ---------------------------------------------------
[0]MoFEM ERROR: MoFEM version 0.6.8 (MOAB 4.9.3pre Petsc Release Version 3.7.4, unknown )
[0]MoFEM ERROR: MoFEM git commit id 56cc2cb82a35fe3534f2718ec88ca9c14e093bbc
[0]MoFEM ERROR: See http://mofem.eng.gla.ac.uk/mofem/html/guidelines_bug_reporting.html for bug reporting.
[0]MoFEM ERROR: See http://mofem.eng.gla.ac.uk/mofem/html/faq_and_bugs.html for trouble shooting.
[0]MoFEM ERROR: Vertex of arc-length field not found
[0]MoFEM ERROR: #1 buildArcLengthField() line 948 in /Users/likask/MyBuild/um_opt/users_modules/fracture_mechanics/src/impl/CrackPropagation.cpp
[0]MoFEM ERROR: #2 buildProblemFields() line 5409 in /Users/likask/MyBuild/um_opt/users_modules/fracture_mechanics/src/impl/CrackPropagation.cpp
[0]MoFEM ERROR: #3 createProblemDataStructures() line 5477 in /Users/likask/MyBuild/um_opt/users_modules/fracture_mechanics/src/impl/CrackPropagation.cpp
[0]MoFEM ERROR: #4 main() line 157 in /Users/likask/MyBuild/um_opt/users_modules/fracture_mechanics/crack_propagation.cpp
#PETSc Option Table entries:
-arc_alpha 0.1
-arc_beta 0
-arc_length_ksp_atol 1e-12
-arc_length_ksp_max_it 200
-arc_length_ksp_rtol 1e-6
-arc_length_ksp_type fgmres
-arc_s 1e-3
-elastic_ksp_atol 1e-12
-elastic_ksp_converged_reason
-elastic_ksp_max_it 100
-elastic_ksp_monitor
-elastic_ksp_rtol 1e-12
-elastic_ksp_stol 0
-elastic_ksp_type fgmres
-elastic_mg_coarse_ksp_type gmres
-elastic_mg_coarse_pc_factor_mat_solver_package mumps
-elastic_mg_coarse_pc_type lu
-elastic_pc_mg_log
-elastic_pc_mg_smoothdown 5
-elastic_pc_mg_smoothup 5
-elastic_pc_mg_type multiplicative
-elastic_pc_type mg
-elastic_snes_atol 1e-8
-elastic_snes_converged_reason
-elastic_snes_linesearch_type basic
-elastic_snes_max_fail 100
-elastic_snes_max_linear_solve_fail 100
-elastic_snes_monitor
-elastic_snes_rtol 1e-8
#End of PETSc Option Table entries
[0]MoFEM ERROR: -- MoFEM End of Error Message -- send entire error message to mofem-group@googlegroups.com --

Error handling should be used as in initial email. You can see how is implemented and should be used here
http://mofem.eng.gla.ac.uk/mofem/html/definitions_8h.html#add80e5ef5f847b2d4b637029f0f671c3
where error catcher is here
http://mofem.eng.gla.ac.uk/mofem/html/definitions_8h.html#a1e74d797bf522e2b291419cddab27835
and implementation of ErrorCheckerCode is here
http://mofem.eng.gla.ac.uk/mofem/html/struct_mo_f_e_m_1_1_error_checker_code.html

[ignat...@gmail.com]

Hi all,

Some extra information regarding usage of  MoFEMFunctionReturn(0);.

When a function begins with MoFEMFunctionBegin;, then MoFEMFunctionReturn(0); should appear only at the end of the function while errors handled in the middle of the function would be done using MoFEMFunctionReturnHot(0);.

Ignatios