tnl-dev issueshttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues2019-11-04T08:24:46Zhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/54How to compile tutorials.2019-11-04T08:24:46ZTomáš OberhuberHow to compile tutorials.Add information, how to compile tutorials. For example -DHAVE_CUDA is important.Add information, how to compile tutorials. For example -DHAVE_CUDA is important.Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/53Bug in analytic functions2019-11-07T13:28:16ZMatouš FenclBug in analytic functionsAnalytic functions as input MeshFunction in Hamilton-Jacobi solver with MPI on GPU give bad values.
Generated function from *tnl-init* is passed into *tnl-direct-eikonal-solver*. TNL devides input MeshFunction into blocks, which number depends on number of processes. Devided MeshFunction that we get in file *tnlDirectEikonalProblem_impl.h* in function *Solve()* has invalid values.
Starting script is attached.
[tnl-run-dir-eik-solver](/uploads/f3a60b9e323f9bbecedbf3f23f3f1f9e/tnl-run-dir-eik-solver)Analytic functions as input MeshFunction in Hamilton-Jacobi solver with MPI on GPU give bad values.
Generated function from *tnl-init* is passed into *tnl-direct-eikonal-solver*. TNL devides input MeshFunction into blocks, which number depends on number of processes. Devided MeshFunction that we get in file *tnlDirectEikonalProblem_impl.h* in function *Solve()* has invalid values.
Starting script is attached.
[tnl-run-dir-eik-solver](/uploads/f3a60b9e323f9bbecedbf3f23f3f1f9e/tnl-run-dir-eik-solver)Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/52Meshes todo list2019-11-05T11:55:06ZJakub KlinkovskýMeshes todo list## Mesh
- [x] write tests for `Mesh` traverser
- [x] rewrite `Traverser` using `ParallelFor`
- [ ] refactor `MeshFunction`
- [ ] implement `MeshFunctionView`
- [ ] write tests
- [ ] implement `DistributedMesh`
- wrapper around `Mesh` (to store the local mesh) + ghost entities - local mesh includes only the local entities in the storage layers, but subentity and superentity maps include indices even for the ghost cells
- local arrays for each mesh layer: `ghostEntities`, `localEntities`
- for `getEntity`, we need mapping from global indices to local indices - easy for local entities (rank offsets), but ghost entities may be discontinuous
- local index mappings (index arrays for efficient iteration):
- `ghosts` (1:1 with `ghostEntities`)
- `local` (1:1 with `localEntities`)
- `ghostNeighbours` (entities which are ghosts on other ranks - for synchronization)
- `localInternal` (not ghosts on any ranks)
- `boundary` (global domain boundary) - stored in the local mesh
- `interior` (global domain interior) - stored in the local mesh
- local decompositions: `local = ghostNeighbours + localInternal`, `local = boundary + interior`
- [ ] write `MeshView`, `DistributedMeshView` etc.
- support for sub-configurations (light views can be initialized by a full mesh, e.g. a view including only cells, vertices and links from cells to their subvertices) - the same can be done with `Mesh`'s copy-constructor
- [ ] implement `forAll`, `forBoundary`, `forInternal` methods like in `NDArray`
- What should be passed to the lambda function? Just the index, or index + mesh entity + mesh (pointer or view)? The former is not very useful and the latter is not very efficient...
- [ ] writer for the XML-based VTK format: see #6
- [ ] `TypeResolver`: `resolveMeshType`, `loadMesh`, `decomposeMesh`:
- [ ] better detection of the format (currently based on the file name suffix)
- [ ] file detection is done twice: once for `resolveMeshType`, then again for `loadMesh`
- [ ] `MeshTypeResolver`: static configuration of the default types for `Real`, `GlobalIndex`, etc.
- [ ] fix/improve the implementation of entity orientation
- [ ] mesh tags (arrays containing user-specified tags for each entity)
## Grid
- [ ] `getEntityIndex()` should be removed from grid - users should call `entity.getIndex()`
- [ ] `getEntity()` and `getEntitiesCount()` should have `int Dimension` template parameter
- [ ] `isBoundaryEntity()` should be moved from `GridEntity` to `Grid` - it is not only an entity attribute, it is always bound to the particular mesh.
Generally, entities might be shared between multiple submeshes, so the method does not make sense in the general interface.
There migh also be read-only views for partitions of the mesh (see vienna-grid).
- [ ] the `getMesh()` method should be removed from `GridEntity` - for the same reason as `isBoundaryEntity()`
(it is also an optimization because the size of the entity structure will be smaller)
- [ ] `getCenter()` and `getMeasure()` should be plain functions taking a `Mesh` and `MeshEntity` as parameters.
This is because general MeshEntity stores only indices of the subvertices, the points have to be accessed via Mesh class.
See also [Effective C++ Item 23 Prefer non-member non-friend functions to member functions](https://stackoverflow.com/questions/5989734/effective-c-item-23-prefer-non-member-non-friend-functions-to-member-functions) and the [Open-closed principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle).## Mesh
- [x] write tests for `Mesh` traverser
- [x] rewrite `Traverser` using `ParallelFor`
- [ ] refactor `MeshFunction`
- [ ] implement `MeshFunctionView`
- [ ] write tests
- [ ] implement `DistributedMesh`
- wrapper around `Mesh` (to store the local mesh) + ghost entities - local mesh includes only the local entities in the storage layers, but subentity and superentity maps include indices even for the ghost cells
- local arrays for each mesh layer: `ghostEntities`, `localEntities`
- for `getEntity`, we need mapping from global indices to local indices - easy for local entities (rank offsets), but ghost entities may be discontinuous
- local index mappings (index arrays for efficient iteration):
- `ghosts` (1:1 with `ghostEntities`)
- `local` (1:1 with `localEntities`)
- `ghostNeighbours` (entities which are ghosts on other ranks - for synchronization)
- `localInternal` (not ghosts on any ranks)
- `boundary` (global domain boundary) - stored in the local mesh
- `interior` (global domain interior) - stored in the local mesh
- local decompositions: `local = ghostNeighbours + localInternal`, `local = boundary + interior`
- [ ] write `MeshView`, `DistributedMeshView` etc.
- support for sub-configurations (light views can be initialized by a full mesh, e.g. a view including only cells, vertices and links from cells to their subvertices) - the same can be done with `Mesh`'s copy-constructor
- [ ] implement `forAll`, `forBoundary`, `forInternal` methods like in `NDArray`
- What should be passed to the lambda function? Just the index, or index + mesh entity + mesh (pointer or view)? The former is not very useful and the latter is not very efficient...
- [ ] writer for the XML-based VTK format: see #6
- [ ] `TypeResolver`: `resolveMeshType`, `loadMesh`, `decomposeMesh`:
- [ ] better detection of the format (currently based on the file name suffix)
- [ ] file detection is done twice: once for `resolveMeshType`, then again for `loadMesh`
- [ ] `MeshTypeResolver`: static configuration of the default types for `Real`, `GlobalIndex`, etc.
- [ ] fix/improve the implementation of entity orientation
- [ ] mesh tags (arrays containing user-specified tags for each entity)
## Grid
- [ ] `getEntityIndex()` should be removed from grid - users should call `entity.getIndex()`
- [ ] `getEntity()` and `getEntitiesCount()` should have `int Dimension` template parameter
- [ ] `isBoundaryEntity()` should be moved from `GridEntity` to `Grid` - it is not only an entity attribute, it is always bound to the particular mesh.
Generally, entities might be shared between multiple submeshes, so the method does not make sense in the general interface.
There migh also be read-only views for partitions of the mesh (see vienna-grid).
- [ ] the `getMesh()` method should be removed from `GridEntity` - for the same reason as `isBoundaryEntity()`
(it is also an optimization because the size of the entity structure will be smaller)
- [ ] `getCenter()` and `getMeasure()` should be plain functions taking a `Mesh` and `MeshEntity` as parameters.
This is because general MeshEntity stores only indices of the subvertices, the points have to be accessed via Mesh class.
See also [Effective C++ Item 23 Prefer non-member non-friend functions to member functions](https://stackoverflow.com/questions/5989734/effective-c-item-23-prefer-non-member-non-friend-functions-to-member-functions) and the [Open-closed principle](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle).Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/51Wrappers for STL compatibility2019-10-17T09:34:46ZTomáš OberhuberWrappers for STL compatibilityMake wrappers for easier porting of STL code to TNL. It means, for example, wrapper for TNL::Array which has the same methods as STL vector and so on.Make wrappers for easier porting of STL code to TNL. It means, for example, wrapper for TNL::Array which has the same methods as STL vector and so on.https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/50MpiCommunicator::selectGPU does not work reliably when multiple nodes are sel...2019-10-12T10:22:43ZJakub KlinkovskýMpiCommunicator::selectGPU does not work reliably when multiple nodes are selectedThe computation of "node rank" is problematic - maybe `MPI_Get_processor_name` does not work reliably. Sometimes multiple ranks are assigned the same GPU.The computation of "node rank" is problematic - maybe `MPI_Get_processor_name` does not work reliably. Sometimes multiple ranks are assigned the same GPU.Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/49Rename prefix sum methods in vectors to scan2019-11-08T14:49:39ZJakub KlinkovskýRename prefix sum methods in vectors to scanThe former `PrefixSum` class was renamed to `Scan`, but the methods in vector classes (`Vector`, `VectorView`, `DistributedVector` and `DistributedVectorView`) stayed as `prefixSum` and `segmentedPrefixSum` - see e.g. https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/blob/develop/src/TNL/Containers/Vector.h#L269
While we're renaming things, `exclusiveScan` method should be added as a shortcut for `vector.template scan< TNL::Containers::Algorithms::ScanType::Exclusive >()`. Both methods should be used in the [tutorial](https://mmg-gitlab.fjfi.cvut.cz/doc/tnl/tutorial_03_reduction.html#flexible_scan).The former `PrefixSum` class was renamed to `Scan`, but the methods in vector classes (`Vector`, `VectorView`, `DistributedVector` and `DistributedVectorView`) stayed as `prefixSum` and `segmentedPrefixSum` - see e.g. https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/blob/develop/src/TNL/Containers/Vector.h#L269
While we're renaming things, `exclusiveScan` method should be added as a shortcut for `vector.template scan< TNL::Containers::Algorithms::ScanType::Exclusive >()`. Both methods should be used in the [tutorial](https://mmg-gitlab.fjfi.cvut.cz/doc/tnl/tutorial_03_reduction.html#flexible_scan).Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/48Delete setValue in Matrices::Dense::setDimensions.2019-09-04T14:51:57ZTomáš OberhuberDelete setValue in Matrices::Dense::setDimensions.`this->values.setValue(0.0)` should not be there, it just decreases performance. Check other matrix formats for the same issue.`this->values.setValue(0.0)` should not be there, it just decreases performance. Check other matrix formats for the same issue.Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/47Replace StaticArray::setValue with StaticArray::operator=2019-09-01T19:26:50ZTomáš OberhuberReplace StaticArray::setValue with StaticArray::operator=`StaticArray::getValue` should be replaced with `operator=` as well as it is in `Array`. I have created static array assignment class in `Containers/Algorithms/StaticArrayAssignment.h`, however, `IsStaticArrayType< T >` does not work for integral types since they do not have `T::getSize` (`TypeTraits.h:146`). This should be fixed first.`StaticArray::getValue` should be replaced with `operator=` as well as it is in `Array`. I have created static array assignment class in `Containers/Algorithms/StaticArrayAssignment.h`, however, `IsStaticArrayType< T >` does not work for integral types since they do not have `T::getSize` (`TypeTraits.h:146`). This should be fixed first.Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/46Remove getType() methods2019-11-08T14:49:39ZJakub KlinkovskýRemove getType() methodsThey are not necessary, because `std::type_info::name` either returns a human-readable string (MSVC, IBM, Oracle) or can be demangled (GCC, Clang). See https://en.cppreference.com/w/cpp/types/type_info/nameThey are not necessary, because `std::type_info::name` either returns a human-readable string (MSVC, IBM, Oracle) or can be demangled (GCC, Clang). See https://en.cppreference.com/w/cpp/types/type_info/nameJakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/45Parallelize segmented prefix-sum with OpenMP2019-08-14T20:39:50ZJakub KlinkovskýParallelize segmented prefix-sum with OpenMPThe implementation of segmented prefix-sum for `Host` is only sequential.The implementation of segmented prefix-sum for `Host` is only sequential.https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/44Extended NDArray operations2019-08-14T12:24:52ZJakub KlinkovskýExtended NDArray operationsAfter !18 the following things remain to be implemented:
## Features
- [ ] implement generic assignment operator
- [x] support any value, device and index types
- [ ] support any permutation
- [ ] support copies to and from non-contiguous memory (e.g. subarrays)
- [ ] add support for different allocators (c.f. `Array` implementation)
## Applications
- [ ] storage for `VectorField` in TNL
- [ ] subarrays: writing 1D and 2D slices into VTK
## Operations
- [ ] `reduce_along_axis`, `reduce_along_axes` - generalized multireductions - see also https://bitbucket.org/eigen/eigen/src/default/unsupported/Eigen/CXX11/src/Tensor/README.md?at=default&fileviewer=file-view-default#markdown-header-reduction-operations
- [ ] `apply_along_axis` - apply a function to all 1D slices along given axis (challenge: parallelization of outer or inner function)
- Note that unlike [numpy.apply_along_axis](https://docs.scipy.org/doc/numpy/reference/generated/numpy.apply_along_axis.html), the inner function cannot change the array dimension/shape.
- Note that the similar NumPy function, [apply_over_axes](https://docs.scipy.org/doc/numpy/reference/generated/numpy.apply_over_axes.html), is not applicable to NDArray because the slices along different axes have different type so a single function cannot be applied to them. Also, even in NumPy it is interesting only with the change of dimension/shape.
- [ ] reordering of ND arrays along any axis (currently hardcoded in `tnl-mhfem` only for one specific layout of dofs)
- [ ] other [NumPy array manipulation routines](https://docs.scipy.org/doc/numpy/reference/routines.array-manipulation.html) - logical re-shaping and transpose-like operations (i.e. return a view with different sizes or permutation of axes without changing the data)
- [ ] [Eigen geometrical operations on tensors](https://bitbucket.org/eigen/eigen/src/default/unsupported/Eigen/CXX11/src/Tensor/README.md?at=default&fileviewer=file-view-default#markdown-header-geometrical-operations)
## Benchmarks
- [ ] compilation time depending on the number of dimensions, number of ndarrays in code, ...
- [ ] overhead of the indexing calculation for high-dimensional array
- [ ] operations
- [ ] comparison with [RAJA](https://github.com/LLNL/RAJA)
identity perm, set: 1D bandwidth: 9.4718 GB/s, 6D bandwidth: 8.52481 GB/s (9% difference)
identity perm, assign: 1D bandwidth: 11.503 GB/s, 6D bandwidth: 11.0063 GB/s (4.5% loss compared to 1D)
reverse perm, assign: 6D bandwidth: 9.58735 GB/s (13% loss compared to identity 6D)
- [ ] comparison with OpenFOAM - `ScalarField`, `VectorField`, `TensorField`, operations like tensor*vector (locally on mesh cells)After !18 the following things remain to be implemented:
## Features
- [ ] implement generic assignment operator
- [x] support any value, device and index types
- [ ] support any permutation
- [ ] support copies to and from non-contiguous memory (e.g. subarrays)
- [ ] add support for different allocators (c.f. `Array` implementation)
## Applications
- [ ] storage for `VectorField` in TNL
- [ ] subarrays: writing 1D and 2D slices into VTK
## Operations
- [ ] `reduce_along_axis`, `reduce_along_axes` - generalized multireductions - see also https://bitbucket.org/eigen/eigen/src/default/unsupported/Eigen/CXX11/src/Tensor/README.md?at=default&fileviewer=file-view-default#markdown-header-reduction-operations
- [ ] `apply_along_axis` - apply a function to all 1D slices along given axis (challenge: parallelization of outer or inner function)
- Note that unlike [numpy.apply_along_axis](https://docs.scipy.org/doc/numpy/reference/generated/numpy.apply_along_axis.html), the inner function cannot change the array dimension/shape.
- Note that the similar NumPy function, [apply_over_axes](https://docs.scipy.org/doc/numpy/reference/generated/numpy.apply_over_axes.html), is not applicable to NDArray because the slices along different axes have different type so a single function cannot be applied to them. Also, even in NumPy it is interesting only with the change of dimension/shape.
- [ ] reordering of ND arrays along any axis (currently hardcoded in `tnl-mhfem` only for one specific layout of dofs)
- [ ] other [NumPy array manipulation routines](https://docs.scipy.org/doc/numpy/reference/routines.array-manipulation.html) - logical re-shaping and transpose-like operations (i.e. return a view with different sizes or permutation of axes without changing the data)
- [ ] [Eigen geometrical operations on tensors](https://bitbucket.org/eigen/eigen/src/default/unsupported/Eigen/CXX11/src/Tensor/README.md?at=default&fileviewer=file-view-default#markdown-header-geometrical-operations)
## Benchmarks
- [ ] compilation time depending on the number of dimensions, number of ndarrays in code, ...
- [ ] overhead of the indexing calculation for high-dimensional array
- [ ] operations
- [ ] comparison with [RAJA](https://github.com/LLNL/RAJA)
identity perm, set: 1D bandwidth: 9.4718 GB/s, 6D bandwidth: 8.52481 GB/s (9% difference)
identity perm, assign: 1D bandwidth: 11.503 GB/s, 6D bandwidth: 11.0063 GB/s (4.5% loss compared to 1D)
reverse perm, assign: 6D bandwidth: 9.58735 GB/s (13% loss compared to identity 6D)
- [ ] comparison with OpenFOAM - `ScalarField`, `VectorField`, `TensorField`, operations like tensor*vector (locally on mesh cells)Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/43Implement distributed prefix-sum with MPI2019-08-17T18:35:47ZJakub KlinkovskýImplement distributed prefix-sum with MPIAny implementation for `DistributedVector` and `DistributedVectorView` is missing.Any implementation for `DistributedVector` and `DistributedVectorView` is missing.Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/42Implement parallel prefix-sum with OpenMP2019-08-17T18:35:46ZJakub KlinkovskýImplement parallel prefix-sum with OpenMPThe specialization of `PrefixSum` for host is only sequential, any parallelization is missing.The specialization of `PrefixSum` for host is only sequential, any parallelization is missing.Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/41Implement argMin and argMax for DistributedVector and DistributedVectorView2019-08-10T16:30:18ZJakub KlinkovskýImplement argMin and argMax for DistributedVector and DistributedVectorView`argMin` and `argMax` are the only operations which are not yet implemented for `DistributedVector` and `DistributedVectorView`.
The relevant tests are disabled, see [VectorUnaryOperationsTest.h:518](https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/commit/f9f3959e3b406f714f98d22e8cc27c924ab26e14#a43e13a5e5f5b4ee5190413c9fa76ccb0907496e_401_518).`argMin` and `argMax` are the only operations which are not yet implemented for `DistributedVector` and `DistributedVectorView`.
The relevant tests are disabled, see [VectorUnaryOperationsTest.h:518](https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/commit/f9f3959e3b406f714f98d22e8cc27c924ab26e14#a43e13a5e5f5b4ee5190413c9fa76ccb0907496e_401_518).Jakub KlinkovskýJakub Klinkovskýhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/40Optimize scalar product (reduction) on CPU2019-10-12T10:24:07ZTomáš OberhuberOptimize scalar product (reduction) on CPUBenchmarks show that our implementation of scalar product on CPU is very slow.
```
scalar product 400000 CPU 5.4616 0.00109134 N/A
scalar product 400000 CPU ET 4.96865 0.00119962 0.909742
scalar product 400000 CPU BLAS 17.7799 0.000335237 3.25543
```
Since ET (expression templates) and non-ET version behaves almost the same, it seems that even the original implementation before switching to ET was not optimal. We should check the implementation of scalar product in BLAS and improve it.Benchmarks show that our implementation of scalar product on CPU is very slow.
```
scalar product 400000 CPU 5.4616 0.00109134 N/A
scalar product 400000 CPU ET 4.96865 0.00119962 0.909742
scalar product 400000 CPU BLAS 17.7799 0.000335237 3.25543
```
Since ET (expression templates) and non-ET version behaves almost the same, it seems that even the original implementation before switching to ET was not optimal. We should check the implementation of scalar product in BLAS and improve it.https://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/39Add variadic template parameter to Reduction for user defined arguments2019-08-11T18:45:06ZTomáš OberhuberAdd variadic template parameter to Reduction for user defined argumentsAdd variadic template parameter to Reduction for user defined arguments. The arguments would be passed to fetcher.Add variadic template parameter to Reduction for user defined arguments. The arguments would be passed to fetcher.Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/38Reimplement StaticVectorExpressions using StaticFor.2019-08-14T18:13:43ZTomáš OberhuberReimplement StaticVectorExpressions using StaticFor.Reimplement StaticVectorExpressions using StaticFor as it is done in StaticArray and StaticVector.Reimplement StaticVectorExpressions using StaticFor as it is done in StaticArray and StaticVector.Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/37Add method ParameterContainer::getList2019-07-14T11:06:49ZTomáš OberhuberAdd method ParameterContainer::getListFetching a list of parameters from the ParameterContainer works as follows now:
```
const auto& list = parameters.getParameter< std::vector< String > >( "list" );
```
It should be replaced with
```
const auto& list = parameters.getList< String >( "list" );
```Fetching a list of parameters from the ParameterContainer works as follows now:
```
const auto& list = parameters.getParameter< std::vector< String > >( "list" );
```
It should be replaced with
```
const auto& list = parameters.getList< String >( "list" );
```Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/36addEntryEnum does not work for list entry.2019-07-14T11:06:39ZTomáš OberhuberaddEntryEnum does not work for list entry.ConfigDescription crashes when one tries to define entry enum values using adEntryEnum for list entry. For example like this:
```
configDescription.addList< String >( "string-list" );
configDescription.eddEntryEnum< String >( "entry" );
```
The problem seems to be on ConfigDescription.h:139 where the entry is being cast to EntryType which is std::vector< String > but not String.ConfigDescription crashes when one tries to define entry enum values using adEntryEnum for list entry. For example like this:
```
configDescription.addList< String >( "string-list" );
configDescription.eddEntryEnum< String >( "entry" );
```
The problem seems to be on ConfigDescription.h:139 where the entry is being cast to EntryType which is std::vector< String > but not String.Tomáš OberhuberTomáš Oberhuberhttps://mmg-gitlab.fjfi.cvut.cz/gitlab/tnl/tnl-dev/issues/35Overriding of RealType in vertical expressions2019-08-10T16:22:17ZTomáš OberhuberOverriding of RealType in vertical expressionsThe original implementation o vector operations allowed to do this:
```
using VectorType = Containers::Vector< bool, Devices::Host >;
VectorType v( 100 );
v.setValue( true);
auto a = v.sum< int >();
```
The sumation would be performed in bool, by default, which would not give correct result. We can, however, simply change it to `int`. In the new implementation, we state
```
a = sum( v );
```
instead. I would like to be able to write `a = sum< int >( v )` but I did not find any way how to do it.
Solution might be `a = sum( ( int ) v )`.The original implementation o vector operations allowed to do this:
```
using VectorType = Containers::Vector< bool, Devices::Host >;
VectorType v( 100 );
v.setValue( true);
auto a = v.sum< int >();
```
The sumation would be performed in bool, by default, which would not give correct result. We can, however, simply change it to `int`. In the new implementation, we state
```
a = sum( v );
```
instead. I would like to be able to write `a = sum< int >( v )` but I did not find any way how to do it.
Solution might be `a = sum( ( int ) v )`.