waLBerla issueshttps://i10git.cs.fau.de/walberla/walberla/-/issues2019-03-21T08:51:29+01:00https://i10git.cs.fau.de/walberla/walberla/-/issues/82introduce contact based pe load balancing2019-03-21T08:51:29+01:00Sebastian Eiblintroduce contact based pe load balancingmake InfoCollection more general to also support contact based load balancingmake InfoCollection more general to also support contact based load balancing4.1https://i10git.cs.fau.de/walberla/walberla/-/issues/79Drop old compilers from CI2019-02-07T15:19:00+01:00Michael Kuronmkuron@icp.uni-stuttgart.deDrop old compilers from CIand update compiler version checks in CMake
|compiler|minimum|current|
|--------|-------|-------|
|Intel |2017 |2019 |
|GCC |5 |8 |
|Clang |4 |7 |
|MSVC |2017 |? |
Minimum CUDA version for C++1...and update compiler version checks in CMake
|compiler|minimum|current|
|--------|-------|-------|
|Intel |2017 |2019 |
|GCC |5 |8 |
|Clang |4 |7 |
|MSVC |2017 |? |
Minimum CUDA version for C++14 is 9.0 So use the [appropriate CUDA versions](https://gist.github.com/ax3l/9489132) for each compiler.
|CUDA|GCC|Clang|Intel|
|----|---|-----|-----|
|9.0 |5-6|none|17 |
|9.1 |5-6|4 |17 |
|9.2 |5-7|4-5 |17 |
|10.0|5-7|4-6 |17-18|
4.1Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/walberla/walberla/-/issues/71Replace deprecated CUDA APIs2019-01-31T13:26:16+01:00Michael Kuronmkuron@icp.uni-stuttgart.deReplace deprecated CUDA APIsThe cuda module currently [uses](https://i10git.cs.fau.de/walberla/walberla/blob/master/src/cuda/Kernel.h) some CUDA API functions that have been deprecated since CUDA 7.0. They should be replaced.
* `cudaConfigureCall`
* `cudaSetupArgu...The cuda module currently [uses](https://i10git.cs.fau.de/walberla/walberla/blob/master/src/cuda/Kernel.h) some CUDA API functions that have been deprecated since CUDA 7.0. They should be replaced.
* `cudaConfigureCall`
* `cudaSetupArgument`
* `cudaLaunch`
Also, these calls are likely the only thing in the way of making Walberla [support AMD GPUs](https://rocm.github.io) in the future. At least in Espresso, all that we needed was [a bunch of `#define`s](https://github.com/espressomd/espresso/blob/python/src/core/cuda_wrapper.hpp) to get it running on AMD.4.1https://i10git.cs.fau.de/walberla/walberla/-/issues/49Make waLBerla work with every metis&parmetis configuration (sp/dp)2019-03-21T08:57:52+01:00Sebastian EiblMake waLBerla work with every metis&parmetis configuration (sp/dp)4.1Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/walberla/walberla/-/issues/48Replace Boost with standard library features wherever possible2021-03-18T11:34:24+01:00Michael Kuronmkuron@icp.uni-stuttgart.deReplace Boost with standard library features wherever possibleFor the 4.0 release, we should minimize the Boost dependency for higher portability and better compiler error messages. Here is a list of Boost libraries and what should happen with them.
No API change:
* [x] `static_assert`
* [x] `cstd...For the 4.0 release, we should minimize the Boost dependency for higher portability and better compiler error messages. Here is a list of Boost libraries and what should happen with them.
No API change:
* [x] `static_assert`
* [x] `cstdint`
* [x] `type_traits`
* [x] `mpl` (should be rewritten to use standard template functionality)
* [x] `enable_if`
* [x] `lexical_cast`
* [x] `bind`
* [x] `random`
* [x] `math`
* [x] `thread`
* [x] `range`
* [x] `chrono`
* [x] `date_time`
* [x] `exception`
* [x] `foreach`
No visible API change:
* [x] `make_shared`, `shared_ptr`, `weak_ptr`, `dynamic_ptr_cast` (because they are imported into the walberla namespace:
* [x] `function` (because implicitly convertible)
API change:
* [x] `regex`
* [x] `tuple` (should be changed to use variadic templates instead. Also, `TypeList` should use variadic templates instead of its custom `boost::tuple` clone)
* [x] `array`, `shared_array`
* [x] `filesystem` (use C++17 version if available, else fall back to boost)
* [x] `optional` (use C++17 version if available, else fall back to boost)
* [x] `any` (use C++17 version if available, else fall back to boost)
Rewrite without Boost:
* [x] `algorithm::string` (replace with appropriate `<algorithm>`s and lambda functions)
* [x] `functional::hash`
* [x] `integer`
* [x] `checked_delete`
* [x] `numeric::conversion::cast`
* [x] `lambda::bind`
* [x] `cast`
* [x] `dynamic_bitset` (replace with `std::vector<bool>`)
* [x] `logic::tribool` (replace with `walberla::optional<bool>` or an `enum`)
* [x] `uuid` (only used as random numbers, so just generate two 64-bit integers, set the type bits as required and print them as a hex string with dashes in the right places)
* [x] `units::detail::utility::demangle`
* [x] `multi_array` (replace with `std::vector` or even `std::array` with appropriate index arithmetic)
Keep:
* `python`
* `property_tree`
* `graph`
Finally:
* [x] Modify the build system to make Boost an optional dependency (if `std::filesystem`, `std::optional` and `std::any` have been found) and disable `python_coupling`, `config::configToBoostPropertyTree`, and `math::EquationSystem` if Boost is not found.4.1Christoph SchwarzmeierChristoph Schwarzmeierhttps://i10git.cs.fau.de/walberla/walberla/-/issues/42possible segfault in DynamicDiffusive load balancer2019-03-21T08:42:26+01:00Sebastian Eiblpossible segfault in DynamicDiffusive load balancer`flow` is initialized with all neighbor ranks. This will segfault for empty processes:
https://i10git.cs.fau.de/walberla/walberla/blob/master/src/blockforest/loadbalancing/DynamicDiffusive.h#L364
Empty processes:
* Will occur when star...`flow` is initialized with all neighbor ranks. This will segfault for empty processes:
https://i10git.cs.fau.de/walberla/walberla/blob/master/src/blockforest/loadbalancing/DynamicDiffusive.h#L364
Empty processes:
* Will occur when started with spare processes.
* The algorithm will not prevent that the last block is given away to its neighbor.
related issues:
* spare processes will never be included since they do not have neighbors (no one to get blocks from)
* in highly imbalanced simulations but with regions of equal weight using global information can cause block transmission even if this is the last one. Also true for block weight /= 0.4.1https://i10git.cs.fau.de/walberla/walberla/-/issues/41possible division by zero in DynamicDiffusive load balancer2019-03-21T13:38:21+01:00Sebastian Eiblpossible division by zero in DynamicDiffusive load balancerIf a block has no outflow division by zero may occur here:
https://i10git.cs.fau.de/walberla/walberla/blob/master/src/blockforest/loadbalancing/DynamicDiffusive.h#L344If a block has no outflow division by zero may occur here:
https://i10git.cs.fau.de/walberla/walberla/blob/master/src/blockforest/loadbalancing/DynamicDiffusive.h#L3444.1Florian SchornbaumFlorian Schornbaumhttps://i10git.cs.fau.de/walberla/walberla/-/issues/39Suppress undefined behaviour warning in Send/Recv Buffer2019-03-20T15:33:26+01:00Dominik Thoennesdominik.thoennes@fau.deSuppress undefined behaviour warning in Send/Recv BufferThe undefined behaviour sanitizer complains about a load of a misaligned address in the send/recv buffer because it write arbitrary data to the pointer.
Since this behaviour is wanted we can suppress the warning by adding an attribute to...The undefined behaviour sanitizer complains about a load of a misaligned address in the send/recv buffer because it write arbitrary data to the pointer.
Since this behaviour is wanted we can suppress the warning by adding an attribute to the function.4.1Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/walberla/walberla/-/issues/1Better documentation for incompressible LB2023-06-25T01:34:51+02:00Florian SchornbaumBetter documentation for incompressible LBAdd documentation to class PDFField (general class documentation, documentation of density related member functions), also refer to papers about incompressible LB.
Maybe even create a new LB tutorial related to this topic ...Add documentation to class PDFField (general class documentation, documentation of density related member functions), also refer to papers about incompressible LB.
Maybe even create a new LB tutorial related to this topic ...4.1https://i10git.cs.fau.de/walberla/walberla/-/issues/138Possible problem in generated cuda kernels2021-03-31T23:39:48+02:00Dominik Thoennesdominik.thoennes@fau.dePossible problem in generated cuda kernelsIf configured with `-DWALBERLA_STL_BOUNDS_CHECKS=ON`
building `CodegenPoissonGPUGeneratedKernel` emits the following error:
`Building CUDA object tests/cuda/CMakeFiles/CodegenPoissonGPUGeneratedKernel.dir/default_codegen/PoissonGPU.cu....If configured with `-DWALBERLA_STL_BOUNDS_CHECKS=ON`
building `CodegenPoissonGPUGeneratedKernel` emits the following error:
`Building CUDA object tests/cuda/CMakeFiles/CodegenPoissonGPUGeneratedKernel.dir/default_codegen/PoissonGPU.cu.o
/usr/include/c++/8/debug/safe_unordered_container.h(71): error: a nonstatic member reference must be relative to a specific object`5.1Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/136ShowcasePipeline2021-03-04T10:42:28+01:00Markus HolzerShowcasePipelineIt would be good to have a pipeline that just tests the compilation of the showcases. Otherwise, compilation errors may be left unrecognized.It would be good to have a pipeline that just tests the compilation of the showcases. Otherwise, compilation errors may be left unrecognized.5.1https://i10git.cs.fau.de/walberla/walberla/-/issues/129Suppress CMake warning about CUDA architectures2021-03-31T23:39:47+02:00Stephan SeitzSuppress CMake warning about CUDA architecturesI'm getting warnings that CMAKE_CUDA_ARCHITECTURES is not set.
```
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) in apps/tutorials/cuda/CMakeLists.txt:
Policy CMP0104 is not set: CMAKE_CUDA...I'm getting warnings that CMAKE_CUDA_ARCHITECTURES is not set.
```
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) in apps/tutorials/cuda/CMakeLists.txt:
Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC,
empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104"
for policy details. Use the cmake_policy command to set the policy and
suppress this warning.
CUDA_ARCHITECTURES is empty for target "01_GameOfLife_cuda".
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) in apps/showcases/PhaseFieldAllenCahn/GPU/CMakeLists.txt:
Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC,
empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104"
for policy details. Use the cmake_policy command to set the policy and
suppress this warning.
CUDA_ARCHITECTURES is empty for target "multiphase".
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) in apps/showcases/PhaseFieldAllenCahn/GPU/CMakeLists.txt:
Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC,
empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104"
for policy details. Use the cmake_policy command to set the policy and
suppress this warning.
CUDA_ARCHITECTURES is empty for target "PhaseFieldCodeGenGPU".
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) in apps/showcases/PhaseFieldAllenCahn/GPU/CMakeLists.txt:
Policy CMP0104 is not set: CMAKE_CUDA_ARCHITECTURES now detected for NVCC,
empty CUDA_ARCHITECTURES not allowed. Run "cmake --help-policy CMP0104"
for policy details. Use the cmake_policy command to set the policy and
suppress this warning.
CUDA_ARCHITECTURES is empty for target "PhaseFieldCodeGenGPU".
This warning is for project developers. Use -Wno-dev to suppress it.
```
```
CMP0104
-------
Initialize ``CMAKE_CUDA_ARCHITECTURES`` when
``CMAKE_CUDA_COMPILER_ID`` is ``NVIDIA``.
Raise an error if ``CUDA_ARCHITECTURES`` is empty.
``CMAKE_CUDA_ARCHITECTURES`` introduced in CMake 3.18 is used to
initialize ``CUDA_ARCHITECTURES``, which passes correct code generation
flags to the CUDA compiler.
Previous to this users had to manually specify the code generation flags. This
policy is for backwards compatibility with manually specifying code generation
flags.
The ``OLD`` behavior for this policy is to not initialize
``CMAKE_CUDA_ARCHITECTURES`` when
``CMAKE_CUDA_COMPILER_ID`` is ``NVIDIA``.
Empty ``CUDA_ARCHITECTURES`` is allowed.
The ``NEW`` behavior of this policy is to initialize
``CMAKE_CUDA_ARCHITECTURES`` when
``CMAKE_CUDA_COMPILER_ID`` is ``NVIDIA``
and raise an error if ``CUDA_ARCHITECTURES`` is empty during generation.
If ``CUDA_ARCHITECTURES`` is set to a false value no architectures
flags are passed to the compiler. This is intended to support packagers and
the rare cases where full control over the passed flags is required.
This policy was introduced in CMake version 3.18. CMake version
3.18.2 warns when the policy is not set and uses ``OLD`` behavior.
Use the ``cmake_policy()`` command to set it to ``OLD`` or ``NEW``
explicitly.
.. note::
The ``OLD`` behavior of a policy is
``deprecated by definition``
and may be removed in a future version of CMake.
Examples
^^^^^^^^
set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES 35 50 72)
Generates code for real and virtual architectures ``30``, ``50`` and ``72``.
set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES 70-real 72-virtual)
Generates code for real architecture ``70`` and virtual architecture ``72``.
set_property(TARGET tgt PROPERTY CUDA_ARCHITECTURES OFF)
CMake will not pass any architecture flags to the compiler.
```5.1Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/128Some tests are not active2021-03-29T18:41:08+02:00Christoph RettingerSome tests are not activeIt was noted that some tests are currently hard-codedly never run or even built:
- time loop (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/tests/timeloop/CMakeLists.txt)
Fixed in !390
- gui (https://i10git.cs.fau.de/walberl...It was noted that some tests are currently hard-codedly never run or even built:
- time loop (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/tests/timeloop/CMakeLists.txt)
Fixed in !390
- gui (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/tests/gui/CMakeLists.txt)
Cannot be tested since its GUI.
- cuda (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/tests/cuda/CMakeLists.txt)
Cannot be tested since we do not have cuda-aware MPI runners in our CI.
- core (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/tests/core/CMakeLists.txt#L26)
Fixed in !429
Is this on purpose?
We should either activate them again (ideally) or remove them completely. Having them uncommented is not a good style and is confusing.5.1Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/125Lbm code generation tests built but not run?2021-03-09T12:22:35+01:00RudolfWeeberLbm code generation tests built but not run?I think, the code generation tests in
tests/lbm/codegen
are compiled but not executed.
The cmake list in tests/lbm has execute test statements for all other tests, but only code generation and compile statements for the code generation t...I think, the code generation tests in
tests/lbm/codegen
are compiled but not executed.
The cmake list in tests/lbm has execute test statements for all other tests, but only code generation and compile statements for the code generation tests. Also, some of the code generation tests need parameter files, which are not specified in CMakeList.txt.
As an experiment, I added
waLBerla_execute_test( NAME LbCodeGenerationExampe COMMAND $<TARGET_FILE:LbCodeGenerationExample> ${CMAKE_CURRENT_SOURCE_DIR}/codegen/LbCodeGenerationExample.prm )
Btw: the binaries for the tests in the lbm/codegen folder land in the lbm/ folder. Is this intended?
Backgroudn:
I'm one of the Espresso core developers (http://espressomd.org) and working on the Espresso-Walberla-LbmPy coupling.
The generated fluctuating MRT fails some very basic test cases with Espresso. To locate the origin of the problem, I need to test it in Walberla, directly.5.1Markus HolzerMarkus Holzerhttps://i10git.cs.fau.de/walberla/walberla/-/issues/124Signed Overflow warnings in CellInterval2021-03-16T10:29:08+01:00Helen SchottenhammlSigned Overflow warnings in CellIntervalFor certain `CellIntervals`, some gcc7 setups throw a `assuming signed overflow does not occur when assuming that (X - c) > X is always false` warning, when using accessing the `begin()` iterator, as there are `int` comparisons in the `e...For certain `CellIntervals`, some gcc7 setups throw a `assuming signed overflow does not occur when assuming that (X - c) > X is always false` warning, when using accessing the `begin()` iterator, as there are `int` comparisons in the `empty()` check. Such cell intervals occur e.g. when consistently setting boundary conditions in refinement applications.
This warning prohibits such code in waLBerla tests, as all warnings are treated as errors and the pipeline (for me it was `gcc_7_hybrid`) will not pass.
NON-WORKING MINIMAL EXAMPLE:
```cpp
#include <blockforest/Initialization.h>
#include <blockforest/SetupBlockForest.h>
#include <core/debug/TestSubsystem.h>
namespace walberla {
const uint_t FieldGhostLayers = uint_t(4);
int main()
{
debug::enterTestMode();
auto blocks = blockforest::createUniformBlockGrid(uint_t(1), uint_t(1), uint_t(1),
uint_t(10), uint_t(10), uint_t(10),
real_t(1), true);
CellInterval domainBB = blocks->getDomainCellBB();
auto ghost = cell_idx_t(FieldGhostLayers);
domainBB.expand( ghost );
// lowerX
CellInterval lowerX( domainBB.xMin(), domainBB.yMin(), domainBB.zMin(),
domainBB.xMin() + ghost - cell_idx_c(1), domainBB.yMax(), domainBB.zMax());
for( const auto cell : lowerX ) {
// DUMMY CODE to avoid unused variable warning - can be anything
WALBERLA_LOG_INFO_ON_ROOT("x=" << cell.x() )
}
return EXIT_SUCCESS;
}
} // namespace walberla
int main()
{
return walberla::main();
}
```5.1https://i10git.cs.fau.de/walberla/walberla/-/issues/123Error message wrong/misleading2020-10-30T21:21:29+01:00Christoph RettingerError message wrong/misleadingWhen building walberla with the CODEGEN flag, but without having the pystencils package installed, Cmake will complain that the pystencils_walberla package is missing (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/CMakeLists.t...When building walberla with the CODEGEN flag, but without having the pystencils package installed, Cmake will complain that the pystencils_walberla package is missing (https://i10git.cs.fau.de/walberla/walberla/-/blob/master/CMakeLists.txt#L567)
Am I right that this should be the pystencils package?5.1Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/walberla/walberla/-/issues/120Coverage job produces empty reports2020-10-21T13:31:13+02:00Michael Kuronmkuron@icp.uni-stuttgart.deCoverage job produces empty reportsSince the recent changes to the coverage job (!291, !296), the nightly run produces [empty coverage reports](http://walberla.pages.walberla.net/-/walberla/-/jobs/406087/artifacts/coverage/coverage.html).
https://i10git.cs.fau.de/walberl...Since the recent changes to the coverage job (!291, !296), the nightly run produces [empty coverage reports](http://walberla.pages.walberla.net/-/walberla/-/jobs/406087/artifacts/coverage/coverage.html).
https://i10git.cs.fau.de/walberla/walberla/-/jobs/406087:
```
$ gcovr -r $CI_PROJECT_DIR -f ".*\\/src\\/.*" -k
2711 ------------------------------------------------------------------------------
2712 GCC Code Coverage Report
2713 Directory: /builds/walberla/walberla
2714 ------------------------------------------------------------------------------
2715 File Lines Exec Cover Missing
2716 ------------------------------------------------------------------------------
2717 ------------------------------------------------------------------------------
2718 TOTAL 0 0 --%
2719 ------------------------------------------------------------------------------
```5.1https://i10git.cs.fau.de/walberla/walberla/-/issues/118wrapper for nvtx is broken2021-03-26T02:41:22+01:00Dominik Thoennesdominik.thoennes@fau.dewrapper for nvtx is brokenThe wrapper for the nvtx library is broken:
https://i10git.cs.fau.de/walberla/walberla/-/blob/master/src/cuda/NVTX.h
see for example this CI job:
https://i10git.cs.fau.de/walberla/walberla/-/jobs/396032The wrapper for the nvtx library is broken:
https://i10git.cs.fau.de/walberla/walberla/-/blob/master/src/cuda/NVTX.h
see for example this CI job:
https://i10git.cs.fau.de/walberla/walberla/-/jobs/3960325.1Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/walberla/walberla/-/issues/114FindBoost CMake2020-12-14T17:56:50+01:00Dominik Thoennesdominik.thoennes@fau.deFindBoost CMakeOn Ubuntu 20.04 with boost 1.71 cmake emmits the follow warning:
```
CMake Warning at walberla/cmake/FindBoost.cmake:896 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
```
since our cur...On Ubuntu 20.04 with boost 1.71 cmake emmits the follow warning:
```
CMake Warning at walberla/cmake/FindBoost.cmake:896 (message):
New Boost version may have incorrect or missing dependencies and imported
targets
```
since our current FindBoost currently only supports up to version 1.70.
Our FindBoost.cmake is a copy of the official FindBoost in the cmake git from March 2019.
However, simply updating to the newest version of the FindBoost file from the official cmake git does not work since it contains
```
cmake_policy(SET CMP0102 NEW)
```
which was introduced in CMake 3.17 and leads to an error in lower versions.
So we have three options:
* keep the warning
* adjust the FindBoost.cmake manually which makes it hard to update in the future
* remove our own FindBoost.cmake and hope that we will not run into a configuration where boost is newer cmake
I would vote for option three.
What do others think? Especially @eibl since you introduced our copy of FindBoost5.1https://i10git.cs.fau.de/walberla/walberla/-/issues/112generate_sweep can only take one field swap2020-07-13T09:43:50+02:00Markus Holzergenerate_sweep can only take one field swapif generate_sweep is used with more than one field swaps the generated code doesn't work
Example:
```
generate_sweep(ctx, 'allen_cahn_lb', allen_cahn_update_rule, field_swaps=[(h, h_tmp), (C, C_tmp)])
```
produces:
```
auto it = cache_l...if generate_sweep is used with more than one field swaps the generated code doesn't work
Example:
```
generate_sweep(ctx, 'allen_cahn_lb', allen_cahn_update_rule, field_swaps=[(h, h_tmp), (C, C_tmp)])
```
produces:
```
auto it = cache_lb_phase_field_.find( lb_phase_field );
if( it != cache_lb_phase_field_.end() )
{
lb_phase_field_tmp = *it;
}
else
{
lb_phase_field_tmp = lb_phase_field->cloneUninitialized();
cache_lb_phase_field_.insert(lb_phase_field_tmp);
}
GhostLayerField<double, 1> * phase_field_tmp;
// Getting temporary field phase_field_tmp
auto it = cache_phase_field_.find( phase_field );
```
This fails to compile because the variable *it* gets declared two times5.1