hyteg issueshttps://i10git.cs.fau.de/hyteg/hyteg/-/issues2023-04-05T14:59:26+02:00https://i10git.cs.fau.de/hyteg/hyteg/-/issues/206Evaluate seems broken2023-04-05T14:59:26+02:00Andreas BurkhartEvaluate seems brokenI wanted to test some implementation against evaluate in terms of speed and noticed some strange behaviour of P1Function::evaluate and P2Function::evaluate. If you want to evaluate at one of the DoFs evaluate seems to return 0 everywhere...I wanted to test some implementation against evaluate in terms of speed and noticed some strange behaviour of P1Function::evaluate and P2Function::evaluate. If you want to evaluate at one of the DoFs evaluate seems to return 0 everywhere in case of a P1 Function and 0 at specific DoFs in case of a P2 Function.
I've created a branch called _"burk/evaluate"_ with a minimal example in _"tests/hyteg/evaluateTest.cpp"_.
In this example I interpolate a function with evaluations of another function (in this case a function which is 1 everywhere).
This is the result in case of a P2 Function: DoFs where evaluate gives 0 (without indicating that it could not find an associated element by returning false) which seem to follow a pattern.
![evaluate](/uploads/99a7c904addce039f7ad042b837fe5a5/evaluate.png)
This certainly is not a pressing issue as we don't want to use evaluate anyway if it can be helped, but I thought to document the issue at least.Marcus MohrMarcus Mohrhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/24Implement selective communication (in order to not update certain primitives)2019-12-05T16:40:59+01:00Nils KohlImplement selective communication (in order to not update certain primitives)During the communication some primitives possibly shall not be updated.
This might be solved by
1. skipping the unpack on the receiver side
-> no performance gain but secure
2. skipping the send on the sender side and the receive ...During the communication some primitives possibly shall not be updated.
This might be solved by
1. skipping the unpack on the receiver side
-> no performance gain but secure
2. skipping the send on the sender side and the receive on the receiver side
-> the caller must prevent the send on a different process than it needs to prevent the receive on, hard to get that rightDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/29BufferedCommunicator fails when using parallel sends / recvs via OpenMPBuffer...2019-11-07T14:17:37+01:00Nils KohlBufferedCommunicator fails when using parallel sends / recvs via OpenMPBufferSystemLikely there are race conditions when invoking the pack / unpack (send / recv) callbacks. Maybe there is more to it..
Switched to serial sends / recvs now, seems to work fine.
Unsure whether this causes a huge performance drop -> profi...Likely there are race conditions when invoking the pack / unpack (send / recv) callbacks. Maybe there is more to it..
Switched to serial sends / recvs now, seems to work fine.
Unsure whether this causes a huge performance drop -> profile first before fix!
Also: only an issue when building with OpenMP.Nils KohlNils Kohlhttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/55Communicators of composite functions do not have any PackInfos attached.2019-07-11T15:40:15+02:00Nils KohlCommunicators of composite functions do not have any PackInfos attached.Dominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/45Unnecessary communication during interpolate, add, assign2019-02-18T16:44:08+01:00Nils KohlUnnecessary communication during interpolate, add, assignCurrently (in various DoF spaces) we communicate the halos during the LA routines interpolate, add and assign although it is not strictly necessary since all of them only update the local DoFs and only depend on local DoFs.
It would be ...Currently (in various DoF spaces) we communicate the halos during the LA routines interpolate, add and assign although it is not strictly necessary since all of them only update the local DoFs and only depend on local DoFs.
It would be more consequent to let routines that need updated halos pull them when necessary (e.g. operators - before stencils are applied).
Resolving this issue
1. would clear up which routines really depend on updated halos
2. could increase performance as it might safe time that is currently spent on unnecessary communication (however, shifting the communication to other routines could also decrease performance since we might not be able to overlap it with computation in some cases)https://i10git.cs.fau.de/hyteg/hyteg/-/issues/72Number of global MPI reduce ops in P2Function::dot()?2018-07-26T07:29:54+02:00Marcus MohrNumber of global MPI reduce ops in P2Function::dot()?Hi,
taking a look at the `P2Function::dot()` I see that there are two invocations of `walberla::mpi::allReduceInplace()`, one each by
- VertexDoFFunction< ValueType >::dot()
- EdgeDoFFunction< ValueType >::dot()
Having no insight into ...Hi,
taking a look at the `P2Function::dot()` I see that there are two invocations of `walberla::mpi::allReduceInplace()`, one each by
- VertexDoFFunction< ValueType >::dot()
- EdgeDoFFunction< ValueType >::dot()
Having no insight into walberla I can of course not be sure, but if this leads to two MPI reduce operations being performed, we should probably, w.r.t. 3D and HPC, avoid this.
My suggestions would be to add another optional parameter to ***DoFFunction::dot() that turns the call to walberla::mpi::allReduceInplace() on or off. Then we could perform the reduce inside P2Function::dot(), same as with
P2Function::getMaxMagnitude(), see [d7a2cc47].
Opinion?
Cheers
MarcusDominik Thoennesdominik.thoennes@fau.deDominik Thoennesdominik.thoennes@fau.dehttps://i10git.cs.fau.de/hyteg/hyteg/-/issues/31Implement PackInfo abstract class for remaining combinations2018-02-13T16:24:29+01:00Nils KohlImplement PackInfo abstract class for remaining combinationsMissing:
* [x] cells
* [ ] ~~communication between primitives with more than one dim difference (e.g. vertex <-> face)~~ for now we do not want to allow thisMissing:
* [x] cells
* [ ] ~~communication between primitives with more than one dim difference (e.g. vertex <-> face)~~ for now we do not want to allow this