hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2022-11-30T10:43:42+01:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/189BufferedCommunicator::startCommunication does not respect parameter `excludeR...2022-11-30T10:43:42+01:00Daniel BauerBufferedCommunicator::startCommunication does not respect parameter `excludeReceivingID`When communicating functions, the `boundaryTypeToSkipDuringAdditiveCommunication` is ignored in some cases:
```c++
// communicate all boundary types
function.communicateAdditively< Cell, Face >( level, true );
/* …do some other useful w...When communicating functions, the `boundaryTypeToSkipDuringAdditiveCommunication` is ignored in some cases:
```c++
// communicate all boundary types
function.communicateAdditively< Cell, Face >( level, true );
/* …do some other useful work… */
// communicate only inner primitives
function.communicateAdditively< Cell, Face >( level, DoFType::All ^ DoFType::Inner, storage, zeroOutDestination );
```
The second communication is wrongly performed for *all* boundary types.
This is caused by the cache for the communication setup introduced in [#19](https://i10git.cs.fau.de/hyteg/hyteg/-/issues/19).
While `directCommunicationFunctions_` depends on `excludeReceivingIDs`, this is not respected by the implementation and the cache from the previous call is reused.https://i10git.cs.fau.de/hyteg/hyteg/-/issues/210VTKOutput for N1E1Function fails in case of non-FP ValueType2023-04-27T16:32:16+02:00Marcus MohrVTKOutput for N1E1Function fails in case of non-FP ValueTypeHi,
I just extended the `VTKOutputTest` to include all the new function classes for which VTKWriters had been implemented:
- P0Function
- DG1Function
- EGFunction
- N1E1VectorFunction
The test checks that we can compile and execute cod...Hi,
I just extended the `VTKOutputTest` to include all the new function classes for which VTKWriters had been implemented:
- P0Function
- DG1Function
- EGFunction
- N1E1VectorFunction
The test checks that we can compile and execute code for exporting scalar and/or fields over $`\mathbb{R}`$ represented by these functions, i.e. when the `ValueType` of the template is `real_t`. Additionally it also checks whether we can export function objects where `ValueType` is `int32_t` and `int64_t`.
In the case of the `N1E1VectorFunction` class the integer part fails, because `N1E1VectorFunction::communicate()` aborts for non-FP types.
```
if constexpr ( !std::is_floating_point< ValueType >::value )
{
WALBERLA_ABORT(
"This function flips the signs of unknowns to accommodate for inconsistent edge orientations. Do not use it to communicate index vectors. Use getDoFs()->communicate instead!" )
}
```
Admittedly, exporting integer fields is not a feature that is much sought after. However, it can be helpful e.g. in inspecting whether our DoF enumerations work correctly. Actually this is the way the test sets up the fields.
I am not overly familiar with the implementation details of `N1E1VectorFunction`. However, the abort message suggest that there is a workaround. Would it be possible to have `communicate()` use that workaround instead of aborting in case of non-FP types?
Cheers
MarcusDaniel BauerDaniel Bauer