You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* std::filesystem compatibility (#210)
* Improve and debug slices (#211)
* CLN: cleanup redefinition of idfx::randm in planet tests (#212)
* Improve lookup table (#214)
* fix slice VTK outputs when they are at a boundary (#215)
* use SlopeLimiter class's PPM implementation (#218)
* fix an overflow in dump restart routines (#219)
* fix a bug identified in gcc 9.3.0 (#220)
* add documentation for global IdefixArrays (#221)
---------
Co-authored-by: Clément Robert <cr52@protonmail.com>
Copy file name to clipboardExpand all lines: doc/source/faq.rst
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,6 +39,13 @@ The compilation stops while compiling Kokkos with ``/usr/include/stdlib.h(58): e
39
39
When using the Intel compiler on a Mac Intel, I get a linking error involving the ``SharedAllocationRecordIvvE18t_tracking_enabledE`` symbol.
40
40
This is a known bug of the Intel Mac compiler with Kokkos. Apparently Intel has decided not to fix it. Check the issue on the `Kokkos git page <https://github.com/kokkos/kokkos/issues/1959>`_.
41
41
42
+
I get an error during *Idefix* link that says there are undefined symbols to std::filesystem
43
+
This is a known bug/limitation of the stdlibc++ provided with gcc8 that does not include C++17 filesystem extensions.
44
+
While *Idefix* auto-detects gcc8 when it is used as the main compiler, it still misses the cases when another compiler
45
+
(like Clang or Intel) is used with gcc8 as a backend.
46
+
You should try to clear up CMakeCache.txt and explicitely add the required link library when calling cmake as in
Copy file name to clipboardExpand all lines: doc/source/reference/setup.cpp.rst
+77Lines changed: 77 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -395,3 +395,80 @@ User-defined analysis
395
395
396
396
User-defined analysis and outputs can be coded in the ``setup.cpp`` file. Follow the
397
397
guidelines in :ref:`output`.
398
+
399
+
I need a global IdefixArray for my Setup
400
+
-----------------------------------------
401
+
402
+
There are situation where you will need one or several global IdefixArrays that can be accessed from different
403
+
functions, e.g. the ``Initflow`` method and the user-defined boundary conditions.
404
+
405
+
It is important to understand that IdefixArrays (equivalent to ``Kokkos::view`` that are references to memory chunks)
406
+
are automatically dealocated when all of the IdefixArrays refereing to that memory chunk have been deleted. This deletion happens either
407
+
implicitly (by a closing scope) in which case the objects contained in the scope are all deleted automatically,
408
+
or explicitly (through a new/delete pair).
409
+
410
+
If you define an IdefixArray in the global scope, it is deleted when the program terminates. Hence deallocation should happen then.
411
+
Except that, according to `Kokkos documentation <https://kokkos.github.io/kokkos-core-wiki/ProgrammingGuide/Initialization.html#finalization>`_, we
412
+
need to call ``Kokkos::finalize`` before the program terminates and this ``finalize`` should be done once all of
413
+
the Kokkos objects have been deleted (including IdefixArray). While *Idefix* makes sure that all of its objects (including the user's ``Setup``) are being deleted before calling ``finalize``,
414
+
a simple IdefixArray in the global scope will not be explicitely deleted, and will typically lead to the following error:
415
+
416
+
.. code-block:: bash
417
+
418
+
terminate called after throwing an instance of 'std::runtime_error'
419
+
what(): Kokkos allocation "MyAwesomeArray" is being deallocated after Kokkos::finalize was called
420
+
421
+
The way to avoid this is to explicitely delete the object when you don't need it anymore. The cleanest way to do this for a setup is to define a "container" class,
422
+
containing all of the arrays you will need in the global scope, and just have a global pointer to an instance of this class, that you eventually delete
423
+
(and which deletes all of the arrays it contains automatically). More explicitely:
424
+
425
+
#. start with a declaration of a class container (that we name MyGlobalClass in this example) and a global pointer to a class instance (note that you can put as many arrays as you want in the class)
426
+
427
+
.. code-block:: c++
428
+
429
+
// Class declaration
430
+
class MyGlobalClass {
431
+
public:
432
+
// Class constructor
433
+
MyGlobalClass(DataBlock &data) {
434
+
//allocate some memory for the array the class contains
#. initialise your global object in the Setup constructor (this will aumatically allocate the array it contains thanks to the class constructor we have defined):
446
+
447
+
.. code-block:: c++
448
+
449
+
Setup::Setup(....) {
450
+
...
451
+
myGlobals = new MyGlobalClass(data);
452
+
...
453
+
}
454
+
455
+
#. to avoid the error message above, don't forget to delete the object on exit in the Setup destructor
0 commit comments