Added a single precision GitHub CI

[najlkin]

This PR adds a single precision parallel build to the GitHub workflow. It relies on the branch najlkin/add-single-ci in github-actions and the corresponding PR: mfem/github-actions#11 , which should be merged prior to this PR.

PR	Author	Editor	Reviewers	Assignment	Approval	Merge
#4262	@najlkin	@tzanio	@dylan-copeland + @v-dobrev	5/11/24	5/16/24	5/18/24

PR Checklist

• Code builds.
• Code passes make style.
• Update CHANGELOG:
  • Is this a new feature users need to be aware of? New or updated example or miniapp?
  • Does it make sense to create a new section in the CHANGELOG to group with other related features?
• Update INSTALL:
  • Had a new optional library been added? If so, what range of versions of this library are required? (Make sure the external library is compatible with our BSD license, e.g. it is not licensed under GPL!)
  • Have the version ranges for any required or optional libraries changed?
  • Does make or cmake have a new target?
  • Did the requirements or the installation process change? (rare)
• Update continuous integration server configurations if necessary (e.g. with new version requirements for each of MFEM's dependencies)
  • .github
  • .appveyor.yml
• Update .gitignore:
  • Check if make distclean; git status shows any files that were generated from the source by the project (not an IDE) but we don't want to track in the repository.
  • Add new patterns (just for the new files above) and re-run the above test.
• New examples:
  • All sample runs at the top of the example source file work.
  • Update examples/makefile:
    • Add the example code to the appropriate SEQ_EXAMPLES and PAR_EXAMPLES variables.
    • Add any files generated by it to the clean target.
    • Add the example binary and any files generated by it to the top-level .gitignore file.
  • Update examples/CMakeLists.txt:
    • Add the example code to the ALL_EXE_SRCS variable.
    • Make sure THIS_TEST_OPTIONS is set correctly for the new example.
  • List the new example in doc/CodeDocumentation.dox.
  • If new examples directory (e.g.examples/pumi), list it in doc/CodeDocumentation.conf.in
  • Companion pull request for documentation in mfem/web repo:
    • Update or add example-specific documentation, see e.g. the src/examples.md.
    • Add the description, labels and screenshots in src/examples.md and src/img.
    • In examples.md, list the example under the appropriate categories, add new categories if necessary.
    • Add a short description of the example in the "Extensive Examples" section of features.md.
• New miniapps:
  • All sample runs at the top of the miniapp source file work.
  • Update top-level makefile and makefile in corresponding miniapp directory.
  • Add the miniapp binary and any files generated by it to the top-level .gitignore file.
  • Update CMake build system:
    • Update the CMakeLists.txt file in the miniapps directory, if the new miniapp is in a new directory.
    • Add/update the CMakeLists.txt file in the new miniapp directory.
    • Consider adding a new test for the new miniapp.
  • List the new miniapp in doc/CodeDocumentation.dox
  • If new miniapps directory (e.g.miniapps/nurbs), add it to MINIAPP_SUBDIRS in the makefile.
  • If new miniapps directory (e.g.miniapps/nurbs), list it in doc/CodeDocumentation.conf.in
  • Companion pull request for documentation in mfem/web repo:
    • Update or add miniapp-specific documentation, see e.g. the src/meshing.md and src/electromagnetics.md files.
    • Add the description, labels and screenshots in src/examples.md and src/img.
    • The miniapps go at the end of the page, and are usually listed only under a specific "Application (PDE)" category.
    • Add a short description of the miniapp in the "Extensive Examples" section of features.md.
• New capability:
  • All new public, protected, and private classes, methods, data members, and functions have full Doxygen-style documentation in source comments. Documentation should include descriptions of member data, function arguments and return values, template parameters, and prerequisites for calling new functions.
  • Pointer arguments and return values must specify whether ownership is being transferred or lent with the call.
  • Any new functions should include descriptions of their intended use e.g. for internal use only, user-facing, etc., along with references to example code whenever possible/appropriate.
  • Consider adding new sample runs in existing examples to highlight the new capability.
  • Consider saving cool simulation pictures with the new capability in the Confluence gallery (LLNL only) or submitting them, via pull request, to the gallery section of the mfem/web repo.
  • If this is a major new feature, consider mentioning it in the short summary inside README (rare).
  • List major new classes in doc/CodeDocumentation.dox (rare).
• Update this checklist, if the new pull request affects it.
• Run make unittest to make sure all unit tests pass.
• Run the tests in tests/scripts.
• (LLNL only) After merging:
  • Update internal tests to include the new features.

[najlkin]

@v-dobrev , as suspected, the build fails 😏 😄

[v-dobrev]

@v-dobrev , as suspected, the build fails 😏 😄

I tested with single precision on various platforms before approving the single precision PR -- I guess the gcc version in this version of Ubuntu has its own issues.

[najlkin]

Yeah, that Ubuntu is really weird 😵‍💫 , it looks like pow(float, float) gives double there. That should not be according to C++98 already. However, my theory is that it does some optimization maybe as the second argument is just an integer casted to float, so it then uses pow(float, int), where was historically some ambiguity about the return type.

[v-dobrev]

I don't think it "optimizes" to pow(float,int) -- even if you have pow(1.1f, 1.1f) the result is still double with gcc for some strange reason. However, if you have using namespace std; then pow(1.1f, 1.1f) becomes float. It looks like in the global scope pow is just pow(double,double) and inside std there is an overload for pow(float,float).

[v-dobrev]

Basically the code

#include <cmath>
#include <iostream>

int main()
{
   std::cout << "sizeof(::pow(1.1f, 1.1f)) = "
             << sizeof(::pow(1.1f, 1.1f)) << std::endl;
   std::cout << "sizeof(std::pow(1.1f, 1.1f)) = "
             << sizeof(std::pow(1.1f, 1.1f)) << std::endl;
   return 0;
}

prints with gcc:

sizeof(::pow(1.1f, 1.1f)) = 8
sizeof(std::pow(1.1f, 1.1f)) = 4

while with clang it prints:

sizeof(::pow(1.1f, 1.1f)) = 4
sizeof(std::pow(1.1f, 1.1f)) = 4

I guess the standard is not clear about the pow overloads for float (and long double) in the global namespace, so each compiler does its own thing.

[v-dobrev]

In any case, it looks like we can just add using namespace std; in (p)minimal-surface.cpp to fix this.

[najlkin]

Yes, seems to be working 😉

[najlkin]

I added najlkin/add-github-ci also to github-actions for a cleaner configuration 👍 .

[najlkin]

It seems to be all working 👍 , just this GitHub web app shows it is waiting for some tests, but they are not present in the setup anymore 😏

[najlkin]

Based on the discussion, this is what needs to be done (in order):

1. Added floating point precision options. github-actions#11 must be merged
2. the new head of mfem/github-actions:master should be tagged (v2.5 probably)
3. the references to najlkin/add-single-ci and 2.4 branches should be replaced by the new v2.5 here
4. this PR should be merged
5. all PRs with new commits should merge in master so the tests run correctly 👍

[v-dobrev]

One suggestion: use flt instead of sgl. Both dbl and flt are in line with the standard abbreviations in https://en.cppreference.com/w/cpp/header/cfloat.

[najlkin]

I do not know, if MFEM_PRECISION is SINGLE or DOUBLE, I would stick to that...

[najlkin]

I mean there is not a single way how to abbreviate "single" 😄 , it should be "sngl", but in three letters that "sgl" is the most suggestive, I think 😉

[v-dobrev]

@dylan-copeland, @tzanio, what do you think about the sgl vs flt discussion? Do you have a preference?

[dylan-copeland]

@dylan-copeland, @tzanio, what do you think about the sgl vs flt discussion? Do you have a preference?

I don't have a strong preference, but we may want to choose something consistent with precision types that may be added in the future, e.g. half, long double, etc. Maybe the first letter plus pr would work better in general, e.g. hpr, spr, dpr, lpr. I'm not sure why it needs to be 3 letters.

[najlkin]

Well, that is another option 😄 . It does not need to be 3 letters, but something short and of the same length ideally as it appears in the test names.

[v-dobrev]

It's true, we don't necessarily need to stick with 3 letters. I'm not sure that dpr will be very clear to someone external. Maybe the abbreviations that will be immediately clear to most people are fp32 and fp64 -- these are also similar to int32 and int64 which are already used.

[v-dobrev]

I merged mfem/github-actions#11 and created v2.5 branch from its master. Let's update this PR to use this new version, v2.5, instead of najlkin/add-single-ci from the actions repo.

[najlkin]

Ok, here we go. Just @v-dobrev , based on the discussion on Slack, the preference was to use tags instead of branches for github-actions to prevent the situation when master was falling behind these branches. @justinlaughlin wanted to add it to CONTRIBUTING.md, but it ended up in the closed mfem/github-actions#13 . In any case, for this PR, it does not change anything as the syntax does not distinguish between branches and tags.

[v-dobrev]

It's probably good to switch to @v2.5 in other files too: mfem-analysis.yml and mfem-sanitizer.yml.

[v-dobrev]

This looks good!

I made a couple small suggestions if you want to include them.

[najlkin]

Done, ready for merging 😉

[tzanio]

Merged in next for testing...

[tzanio]

Thanks, @najlkin !

[tzanio]

I update the [required tests]( (https://github.com/mfem/mfem/settings/branch_protection_rules/144202) for master to the following:

See them in action in #4310 and let me know if something is missing.

[justinlaughlin]

Ok, here we go. Just @v-dobrev , based on the discussion on Slack, the preference was to use tags instead of branches for github-actions to prevent the situation when master was falling behind these branches. @justinlaughlin wanted to add it to CONTRIBUTING.md, but it ended up in the closed mfem/github-actions#13 . In any case, for this PR, it does not change anything as the syntax does not distinguish between branches and tags.

I need to move that into a new PR, thank you for the reminder!