[Flash-X-users] developer's documentation

[O Neal, Jared P]

  *   Physics units no longer contain high-level code, such as Hydro.F90, that iterates over blocks.  Iteration over blocks is moved out to Driver_evolveAll and physics units typically consists of static Fortran routines that work of a per-block basis.  Static Fortran routines, therefore, do not know that tile/block iterators exist.
  *   Static Fortran routines should not take a tile/block descriptor as an argument.  Rather they should accept tile metadata as arguments.
  *   Static Fortran code shall be written such that it will work if tile metadata (e.g., lo, hi, data pointers) are specified with respect to a local index space or global index space.
  *   Static Fortran routines shall not dynamically allocate memory.  All necessary scratch/intermediate data shall be passed in as arguments.

________________________________
From: Flash-X-users <flash-x-users-bounces at lists.cels.anl.gov> on behalf of Dubey, Anshu <adubey at anl.gov>
Sent: Tuesday, July 5, 2022 6:55 PM
To: flash-x-users at lists.cels.anl.gov <flash-x-users at lists.cels.anl.gov>
Subject: Re: [Flash-X-users] developer's documentation


I have added following files into the source for sphinx in Flash-X-docs which will not show up on the web interface, but have some relevant text as promised. Some have very little, but I am working on them fairly regularly.

 create mode 100644 sphinx/source/CodingStandards.rst

 create mode 100644 sphinx/source/FLASH-to-Flash-x.rst

 create mode 100644 sphinx/source/developer_section.rst

 create mode 100644 sphinx/source/namingConventions.rst





From: Flash-X-users <flash-x-users-bounces at lists.cels.anl.gov> on behalf of "Dubey, Anshu" <adubey at anl.gov>
Date: Tuesday, July 5, 2022 at 5:53 PM
To: "flash-x-users at lists.cels.anl.gov" <flash-x-users at lists.cels.anl.gov>
Subject: [Flash-X-users] Some guidelines for Physics Unit Authors



All:



In the meeting today people wanted to know general guidelines for ensuring that their code needs minimal refactoring to work with runtime and recipes. They will be in the developer’s guide, but while that is work in progress, here is a minimal set.



  1.  Keep track of all scalars and data structures that will need to be included for offloading computation to devices other than CPU. Put them in the Unit_data modules with comments attached for each data item that indicate whether data item is to be:
     *   Allocated on device and reused on device as needed
     *   Sent once and reused without need to return
     *   Sent and updated but not returned
     *   Nothing to send, only returned
     *   Sent and returned
  2.  Think about the functionality of your unit that you wish to expose to Driver_evolveAll, put that functionality in the unit level API
  3.  Localize code that is likely to need refactoring later to use performance portability tools.
  4.  Whatever naming convention you are using internally, make it so that search-and-replace can easily make it compatible with the overall naming convention since that is still work in progress.
  5.  As long as your code is not kosher for outsiders to use, put keyword UNOFFICIAL in your config file. This will give an error during setup if someone tries to use it. If you wish to bypass the check you can include the option –with-unofficial=path



These are what I could think of. If others remember or think of something please add.

Best,

Anshu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cels.anl.gov/pipermail/flash-x-users/attachments/20220706/0c11fa97/attachment.html>