1 Topic by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,026

Topic: context

I have found, that the context functionality is not working properly.
Unfortunately, the problem is not easy to fix.

The problem is following:
- before reading context, the dofs and their applied bcs are properly initialized.
-  when context is being read (restored), the dofs are deleted and created again  (see DofManager :: restoreContext). In this step, the information about assigned bcs are lost and this information is not restored, it is restored only when mode is set to CM_Definition

It may seem that the solution would be to set CM_Definition when saving and restoring context. However, this will also not work, as in this case domain  restoreContext deletes all instanciated components. That would be ok, but then all components should read all information when restoring context. This is not the case, for example BoundaryCondition is not restoring its values......

I am working to fix this, but functionality have to be checked before commiting when the changes are made, as its more simple to find out the problem.

bp's Website

2 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,026

Re: context

OK, fixed now. We should think how to add a simple test checking store/restore functionality.

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: context

One straight forward way would be a straight forward test:

if (USE_SM)
    file (GLOB sm_tests RELATIVE "${oofem_TEST_DIR}/sm" "${oofem_TEST_DIR}/sm/*.in")
    foreach (case ${sm_tests})
        add_test (NAME "test_${case}" WORKING_DIRECTORY ${oofem_TEST_DIR}/sm COMMAND ${oofem_cmd} "-f" ${case})
    endforeach (case)
    # A test for writing context files
    add_test (NAME "test_context_w" WORKING_DIRECTORY ${oofem_TEST_DIR}/sm COMMAND ${oofem_cmd} "-f" "beam2d_1.in" "-c")
    # A test for reading context files
    add_test (NAME "test_context_r" WORKING_DIRECTORY ${oofem_TEST_DIR}/sm COMMAND ${oofem_cmd} "-f" "beam2d_2.in" "-r" "1")
endif ()

However, there are several problems with this. For reading, we would need to have a stored binary file, and it will not be compatible with different version, architectures etc.
Adding a script to run two commands could be done, but it wouldn't work together with Valgrind memory check, so I would prefer to avoid that.


The best option would probably be to write, just like beam01 binary, a simple executable which writes then reads a context stream.

4 Reply by bp

  • bp
  • Administrator
  • Offline
  • From: Prague, Czech Rep.
  • Registered: 02-03-2007
  • Posts: 1,026

Re: context

Approach similar to beam01 binary seems good idea, perhaps one could also support python scripts, that can run different stages and even perform some checks.

bp's Website

  • From: Gothenburg, Sweden
  • Registered: 08-09-2009
  • Posts: 1,419

Re: context

We actually used to have python scripts to run oofem then the extractor script, but the main reason i got rid of that was to enable the possibility of automatic Memcheck & Coverage testing.

In particular this type of writing memory blocks in the context files, we definitely want to have automatic memory checking.
So, I want to stress that making a binary like beam01 would be much better for this.