• maybe use shorter identifiers
• maybe decrease precision
• maybe decrease whitespace
• etc.

For some reason, there is a small error in the calculation. It is done in function
nurbs_edge() in file hermes2d/src/mesh/curved.cpp. There is even a test for
this in hermes2d/tests/ but it only passes when tolerance is very large (0.1).
With smaller tolerance the test fails.

• works for computations, does not for visualization

Nonlinear

• hide the necessity of creating the Form descendants from the user & create a method for obtaining the (one?) form with the parameter
• create a database of potential nonlinear forms and insert the above functionality
• test on some simple nonlinearity with cachegrind
• include vector forms

Func

• heuristics?

After discovering that hermes-python seems to require the Master-2.0 branch of Hermes2d, I attempted to build it. But it appears that more recent compilers may be incompatible with the code in the 2.0 branch. I see
error: cannot bind rvalue reference of type ‘double&&’ to lvalue of type ‘XMLMesh::var::value_type’ {aka ‘double’}
and some searching on StackFlow seems to suggest that I need to surround some arguments being passed into some of the calls in mesh_reader_h2d_xml.cpp with a std:move(var) decoration in order to get the code to compile. Does that sound like a correct conclusion?

See

https://docs.google.com/spreadsheet/ccc?key=0AqzCrrrWG9GVdGhVN0lOUzU2eWhBbEp5cFpBWDNyOFE

David, Franta (28.1. 2013)

-> make this more robust

The same valgrind analysis used to identify issue #114 also yielded the more problematic one (which seems to be responsible for several crashes I experienced)!

==16999== Invalid write of size 8
==16999== at 0x55850C7: Hermes::Hermes2D::RefinementSelectors::HcurlProjBasedSelectorstd::complex::precalc_ref_solution(int, Hermes::Hermes2D::Solutionstd::complex, Hermes::Hermes2D::Element, int) (hcurl_proj_based_selector.cpp:223)
==16999== by 0x557C161: Hermes::Hermes2D::RefinementSelectors::ProjBasedSelectorstd::complex::calc_projection_errors(Hermes::Hermes2D::Element_, Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::CandsInfo const&, Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::CandsInfo const&, Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::CandsInfo const&, Hermes::Hermes2D::Solutionstd::complex, double () [12][12], double () [12], double () [12][12]) (proj_based_selector.cpp:265)
==16999== by 0x55745C1: Hermes::Hermes2D::RefinementSelectors::ProjBasedSelectorstd::complex::evaluate_cands_error(Hermes::Hermes2D::Element_, Hermes::Hermes2D::Solutionstd::complex, double, double_) (proj_based_selector.cpp:136)
==16999== by 0x556E131: Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::evaluate_candidates(Hermes::Hermes2D::Element_, Hermes::Hermes2D::Solutionstd::complex, double, double_) (optimum_selector.cpp:602)
==16999== by 0x556E233: Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::select_refinement(Hermes::Hermes2D::Element_, int, Hermes::Hermes2D::Solutionstd::complex, Hermes::Hermes2D::ElementToRefine&) (optimum_selector.cpp:707)
==16999== by 0x548F72F: ZN6Hermes8Hermes2D5AdaptISt7complexIdEE5adaptENS_6vectorIPNS0_19RefinementSelectors8SelectorIS3_EEEEdiid.omp_fn.0 (adapt.cpp:355)
==16999== by 0x6F85EE9: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==16999== by 0x4E39E99: start_thread (pthread_create.c:308)
==16999== by 0x688CCCC: clone (clone.S:112)
==16999== Address 0x14e40970 is 0 bytes after a block of size 5,088 alloc'd
==16999== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16999== by 0x5585158: Hermes::Hermes2D::RefinementSelectors::HcurlProjBasedSelectorstd::complex::precalc_ref_solution(int, Hermes::Hermes2D::Solutionstd::complex, Hermes::Hermes2D::Element, int) (matrix.h:55)
==16999== by 0x557C07A: Hermes::Hermes2D::RefinementSelectors::ProjBasedSelectorstd::complex::calc_projection_errors(Hermes::Hermes2D::Element, Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::CandsInfo const&, Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::CandsInfo const&, Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::CandsInfo const&, Hermes::Hermes2D::Solutionstd::complex, double () [12][12], double () [12], double () [12][12]) (proj_based_selector.cpp:279)
==16999== by 0x55745C1: Hermes::Hermes2D::RefinementSelectors::ProjBasedSelectorstd::complex::evaluate_cands_error(Hermes::Hermes2D::Element_, Hermes::Hermes2D::Solutionstd::complex, double, double_) (proj_based_selector.cpp:136)
==16999== by 0x556E131: Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::evaluate_candidates(Hermes::Hermes2D::Element_, Hermes::Hermes2D::Solutionstd::complex, double, double_) (optimum_selector.cpp:602)
==16999== by 0x556E233: Hermes::Hermes2D::RefinementSelectors::OptimumSelectorstd::complex::select_refinement(Hermes::Hermes2D::Element_, int, Hermes::Hermes2D::Solutionstd::complex_, Hermes::Hermes2D::ElementToRefine&) (optimum_selector.cpp:707)
==16999== by 0x548F72F: _ZN6Hermes8Hermes2D5AdaptISt7complexIdEE5adaptENS_6vectorIPNS0_19RefinementSelectors8SelectorIS3_EEEEdiid._omp_fn.0 (adapt.cpp:355)
==16999== by 0x6F85EE9: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==16999== by 0x4E39E99: start_thread (pthread_create.c:308)
==16999== by 0x688CCCC: clone (clone.S:112)

As shown above, in (hcurl_proj_based_selector.cpp:223) the code writes to curl[i] which is allocated as

//allocate space for Curl
if(precalc_rvals_curl == NULL)
precalc_rvals_curl = new_matrix(H2D_MAX_ELEMENT_SONS, num_gip);

The problems seems to be that num_gip can change during the runtime of the code, but the allocation is fixed! The obvious patch would be to always delete and reallocate precalc_rvals_curl with the current num_gip but I am not sure if this breaks something.

Update: Problem only seems to occur when using mixed triangular-quad-meshes and only when h- or hp-adaptivity is used!

• some basic work in devel branch
• more needed, at least documentation how to write the clone() method.

Delete own_forms in Adapt::~Adapt() etc.

I had a problem compiling "hermes_common" due to INT_MAX (was not defined at the moment). The file "common.h" in the hermes_common/include created a problem for me as the line 33 says: #include"limits". Changing it to either #include"climits" or #include"limits.h" solved my problem (I've put quotation marks instead of greater then and less then signs as web interface didn't allow me to put them).

It should take 1% or similar.

Add possibility to obtain history of Jacobian reuses in the Newton solver run. Similarly as for list of norms and list of damping factors used, one would obtain list of T/F indicating whether the Jacobian has been reused in the given step.

Periodically run hermes-testing/run.sh and check the outcome.

linking suggests adding -fPIC

Only the reasonable ones to API as it slows the code.

Right now only tried successfully for Poisson equation

• try for another equation
• make more robust and 100% integrated
• conditional loading of the tables

Just a detail, but in my opinion, parameter handleMultipleTolerancesAnd of function Newton::set_tolerance should be implicitly set to true. One usually wants to have control over residual norm AND change of solution. It took me some time to figure out what is wrong with calculation (it did not finish convergence)

big time

• including tutorial & examples
• reason: to have a stable version that will last in master for a long time
• including installation instructions (test: both linux & windows)

• there may be an issue just with discontinuous solutions (where observed), but it should work.

When I run my mode-solver code which uses hermes2d, I sometimes get spurious crashes or seg-faults. When I use valgrind to search for the cause of those problems, I find a number of problems. I will add them as separate issues.

The first one is this one:

==16999== at 0x4C2A4BC: operator delete(void_) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16999== by 0x56E0E6B: Hermes::Hermes2D::Spacestd::complex::free_bc_data() (space.cpp:1135)
==16999== by 0x56EA390: Hermes::Hermes2D::Spacestd::complex::assign_dofs(int, int) (space.cpp:923)
==16999== by 0x56E7187: Hermes::Hermes2D::Spacestd::complex::ReferenceSpaceCreator::create_ref_space(bool) (space.cpp:692)
==16999== by 0x44D36E: main (WaveguideModeSolverAdaptiveIterative.cpp:202)
==16999== Address 0xe7c42e0 is 0 bytes inside a block of size 32 alloc'd
==16999== at 0x4C2AC27: operator new[](unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16999== by 0x56F0B83: Hermes::Hermes2D::HcurlSpacestd::complex::get_bc_projection(Hermes::Hermes2D::SurfPos_, int, Hermes::Hermes2D::EssentialBoundaryConditionstd::complex) (space_hcurl.cpp:185)
==16999== by 0x56E9E8A: Hermes::Hermes2D::Spacestd::complex::update_edge_bc(Hermes::Hermes2D::Element, Hermes::Hermes2D::SurfPos_) (space.cpp:1088)
==16999== by 0x56E9FB5: Hermes::Hermes2D::Spacestd::complex::update_edge_bc(Hermes::Hermes2D::Element_, Hermes::Hermes2D::SurfPos_) (space.cpp:1104)
==16999== by 0x56EA16E: Hermes::Hermes2D::Spacestd::complex::update_essential_bc_values() (space.cpp:1125)
==16999== by 0x56EA398: Hermes::Hermes2D::Spacestd::complex::assign_dofs(int, int) (space.cpp:924)
==16999== by 0x56F02A0: Hermes::Hermes2D::HcurlSpacestd::complex::HcurlSpace(Hermes::Hermes2D::Mesh const_, Hermes::Hermes2D::EssentialBCsstd::complex, int, Hermes::Hermes2D::Shapeset) (space_hcurl.cpp:56)
==16999== by 0x56E6F73: Hermes::Hermes2D::Spacestd::complex::ReferenceSpaceCreator::init_construction_hcurl() (space.cpp:725)
==16999== by 0x56E7125: Hermes::Hermes2D::Spacestd::complex::ReferenceSpaceCreator::create_ref_space(bool) (space.cpp:677)

The reason here seems to be the delete of a void* which is not a good idea. Actually, it is undefined behavior (e.g. see http://stackoverflow.com/questions/941832/is-it-safe-to-delete-a-void-pointer)

The pointers in question are bc_data[], defined in hermes2d/include/space/space.h as Hermes::vector<void*> bc_data; I tried converting them to Hermes::vector<Scalar*> bc_data but that caused some problems and I do not have the necessary insight into hermes2d to fix this problem.

The newly added L2MaterialWiseConstSpace does not save. Previously (the ConstSpace in my implementation) it did not save either, but the program did not fail, since "throw Exceptions::Exception("This type of space can not be saved.");" was not present and thus I did not notice.

Also a change of names could be considered:

1. L2MarkerWiseConstSpace (or L2Subdomain....) would be more appropriate, since it does not need to be constant on the whole material (in Agros sense, is it different in Hermes?)
2. HERMES_UTILITY_L2_SPACES is not very clear to me. Could it be related to the (previously discussed) name of the space somehow?