berkeleylab / inference-engine Goto Github PK

We should add a short description to the repo. Something along the lines of:
"A Fortran 2018 <package/module> which enables inference using trained dense neural networks."

See DAG.

Here's the error I get trying to compile with ifx:

layer_s.f90                            failed.
[ 57%] Compiling...
././src/inference_engine/layer_s.f90(22): error #6197: An assignment of different structure types is invalid.   [CONSTRUCT]
    layer%neuron = neuron_t(layer_lines, start+1)
-------------------^

There is a workaround for a nagfor bug in the src dir that can be removed because the latest version of nagfor should have fixed this.

• Remove macro and test to make sure it works
• move .F90 to .f90

Check do-concurrent reduce locality specifier support on different compilers that we are or hope to use to compiler inference-engine, as we may want to add said locality specifier to the code.

The [learn-microphysics-procedures.f90] example demonstrates how to train a neural network to model functions in the mp_thompson.f90 module. A possible next step could be modeling the rest of the procedures in the same module. The full set of procedures is below.

Functions

• REAL FUNCTION GAMMLN(XX)
• REAL FUNCTION GAMMP(A,X)
• REAL FUNCTION WGAMMA(y)
• REAL FUNCTION RSLF(P,T)
• REAL FUNCTION RSIF(P,T)

Subroutines

• SUBROUTINE mp_gt_driver(
  - arguments:

    qv, qc, qr, qi, qs, qg, ni, nr, &
    th, pii, p, dz, dt_in, itimestep, &
    RAINNC, RAINNCV, &
    SNOWNC, SNOWNCV, &
    GRAUPELNC, GRAUPELNCV, SR, &
    ids,ide, jds,jde, kds,kde, &             ! domain dims
    ims,ime, jms,jme, kms,kme, &             ! memory dims
    its,ite, jts,jte, kts,kte               ! tile dims

• subroutine mp_thompson
  - arguments:

     qv1d, qc1d, qi1d, qr1d, qs1d, qg1d, ni1d, &
     nr1d, t1d, p1d, dz1d, &
     pptrain, pptsnow, pptgraul, pptice, &
     kts, kte, dt, i, j

• subroutine qr_acr_qg
  - arguments: none
  - reads/writes: qr_acr_qg_mpt.dat
  - module variables accesses: ____
• subroutine qr_acr_qs
  - arguments: none
  - reads/writes qr_acr_qs_mpt.dat
  - module variables accesses: ____
• subroutine freezeH2O
  - arguments: none
  - reads/writes: freezeH2O_mpt.dat
  - module variables accessed: ____
• subroutine qi_aut_qs
  - arguments: none
  - no reads or writes
  - module variables accessed: ___
• subroutine table_Efrw
  - arguments: none
  - reads/writes: none
  - module variables accessed: ___
• subroutine table_Efsw
  - arguments: none
  - reads/writes: none
  - module variables accessed: ___
• subroutine table_dropEvap
  - arguments: none
  - reads or writes: none
  - module variables accessed: ___
• SUBROUTINE GCF
  - arguments: GAMMCF, A, X , GLN
  - reads or writes: none
  - module variables accessed: ___
• SUBROUTINE GSER - arguments: GAMSER, A, X, GLN`
  - reads or writes: none
  - module variables accessed: ___

Update README based on new directory changes, see comment posted by @rouson in #108 (comment)_

Add cloud-microphysics setup script to CI

See comment posted by @rouson in #108 (comment)_

After new version of ifx released, remove bug workarounds where can.

• Remove ifdef related to associate-stmt in get_key_value in inference_engine_s.F90
• Try to remove ifdef related to associate-stmt in from_file in training_configuration_s.f90
• ...

• Add LICENSE.txt file with copyright notice and license agreement
• Add statement referring to the license at the top of each source file
• Add build instructions to the README.md
• Add a basic ford project file
• Set up the CI to post the ford documentation to GitHub Pages

Currently, the command

fpm test --compiler flang-new --flag "-mmlir -allow-assumed-rank"

yields the trailing output

[ 57%]        inference_engine_m_.f90  done.

error: Semantic errors in ././src/inference_engine/inference_engine_m_.f90
./././src/inference_engine/inference_engine_m_.f90:72:32: error: Result of pure function may not have polymorphic ALLOCATABLE ultimate component '%activation_strategy_'
        type(inference_engine_t) inference_engine
                                 ^^^^^^^^^^^^^^^^
./././src/inference_engine/inference_engine_m_.f90:30:50: Declaration of 'activation_strategy_'
      class(activation_strategy_t), allocatable :: activation_strategy_ ! Strategy Pattern facilitates elemental activation
                                                   ^^^^^^^^^^^^^^^^^^^^
./././src/inference_engine/inference_engine_m_.f90:104:24: error: Result of pure function may not have polymorphic ALLOCATABLE ultimate component '%activation_strategy_'
        type(exchange_t) exchange
                         ^^^^^^^^
./././src/inference_engine/inference_engine_m_.f90:52:50: Declaration of 'activation_strategy_'
      class(activation_strategy_t), allocatable :: activation_strategy_ ! Strategy Pattern facilitates elemental activation
                                                   ^^^^^^^^^^^^^^^^^^^^
<ERROR> Compilation failed for object " src_inference_engine_inference_engine_m_.f90.o "
<ERROR> stopping due to failed compilation
STOP 1

I suggest adding topics such as ann, neural-network, feedforward-neural-network in the About section at https://github.com/BerkeleyLab/inference-engine

./setup.sh runs under directories inference-engine and inference-engine/cloud-microphysics

However ./build/run-fpm.sh run train-cloud-microphysics -- --base training --epochs 10 --start 720

does not run in inference-engine/cloud-microphysics

PR #7 contains a skeletal demonstration of concurrent inference using multiple networks.

To Do

• Finish the space_delimited_strings_to_array() internal function.
• Define an array of inputs for each network
• Write a test

The new test could evaluate the XOR truth table concurrently with each do concurrent iteration using an independent copy of the XOR neural network evaluation. This is potentially faster than the previous sequential evaluation of the truth table in the existing tests.

Each of the three-line do concurrent/dot_product blocks in the [infer] type-bound procedure can be collapsed down to a one-line invocation of matmul. By default, it seems likely that most compilers would generate faster code with matmul, but it's best to be able to compare the two approaches with multiple compilers on multiple platforms to determine whether or not matmul is always superior. Scenarios to consider:

1. Using the compiler's default matmul implementation.
2. Using a compiler option, if available, to switch to an optimized library version of matmul.
3. Using do concurrent with with various optimization flags (-O...) set.
4. Using a compiler option, if available, to offload do concurrent to a GPU.
5. Using a compiler option, if available, to offload matmul to a GPU.

Option 4 and possibly option 5 are available with the Intel ifx compiler as of the 2022.3 version of oneaAPI released two weeks ago. Option 4 and possibly option 5 has also been available with the NVIDIA nvfortran compiler since about 2 years ago, but nvfortran has limited support for Fortran 2008 and extremely limited support for Fortran 2018. I believe our only 2008 features are do concurrent (which nvfortran supports), module function/module subroutine interface bodies, and submodule, which nvfortran might or might not support. Working around the latter two features would require a lot of code revision, but would not be too painful.

Let's develop an alternative implementation of infer that does this and enable switching between the two with a C preprocessor macro something like

#ifdef DO_CONCURRENT_INFER
  module procedure infer
     ! (concurrent infer implementation)
  end procedure
#else
  module procedure infer
     ! (matmul implementation)
  end procedure
#endif