meteoswiss-apn / gtclang Goto Github PK

View Code? Open in Web Editor NEW

4.0 4.0 10.0 1.11 MB

DSL frontend for geophysical applications based on clang

License: MIT License

CMake 3.52% Python 2.72% C++ 91.80% Shell 1.78% Cuda 0.05% Dockerfile 0.12%

gtclang's People

Contributors

Stargazers

Watchers

Forkers

thfabian twicki cosunae stefanmoosbrugger stagno ofuhrer havogt mroethlin lukasm91

gtclang's Issues

Namespace of the generated code

The GridTools generated code is enclosed in namespace gridtools, but since this is user code it should not. Also, I am not sure about including the license/copyright header in the generated code. I would put a "provided with no warranty" disclaimer in it...

Jenkis links to outdated GridTools

We should have a stable release of GT that we're linking against. Currently it is either Carlos' branch or mine. Can we settle on a release and link to that?

Add option for git_url's

as is allowed in gtclang-all:

cmake .. -DDAWN_GIT_URL=https://github.com/<username>/dawn.git

should be possible

(from clang-gridtools #30) protection for temporaries that are output only fields

In case we define some temporary storages, that are written into, but never read back,
it can happen that the generator generates GT stages with no output field (since the temporary is promoted as a local variable)

We need to add a protection for this

// Temporary fields
  temporary_storage lgsA, lgsB, lgsC, lgsRHS;

  Do {
    // This is just the first step!

    // 1. Computation of explicit part of the divergence
    if(first_small_step) {
      // For a_rk() == 1.0 && b_rk() == 0.0 the dycore takes the shortcut of setting pos to nnow,
      // Here we only support the most general version where u,v are pointing to a time interpolated value
      fast_waves_vertical_divergence_helper(divTildeVerticUV, lgsRHS, u, v, acrlat0, crlat1, wgtfacU,
                                          wgtfacV, wgtfacqU, wgtfacqV, dz_dlam, dz_dphi, dz_dlam4,
                                          dz_dphi4);
    }

}

generated stage

struct stage_0_1 {
      using acrlat0 = gridtools::accessor<0, gridtools::enumtype::in, gridtools::extent<0, 0, 0, 0, 0, 0>>;
      using dz_dlam4 = gridtools::accessor<1, gridtools::enumtype::in, gridtools::extent<0, 0, 0, 0, 0, 0>>;
      using dz_dphi4 = gridtools::accessor<2, gridtools::enumtype::in, gridtools::extent<0, 0, 0, 0, 0, 0>>;
      using __tmp_u_sfc_66 = gridtools::accessor<3, gridtools::enumtype::in, gridtools::extent<-1, 0, 0, 0, 0, 0>>;
      using __tmp_v_sfc_67 = gridtools::accessor<4, gridtools::enumtype::in, gridtools::extent<0, 0, -1, 0, 0, 0>>;
      using arg_list = boost::mpl::vector<acrlat0, dz_dlam4, dz_dphi4, __tmp_u_sfc_66, __tmp_v_sfc_67>;

      template <typename Evaluation>
      GT_FUNCTION static void Do(Evaluation& eval, interval_end_plus_1_end_plus_1) {
        gridtools::clang::float_type __local_lgsRHS_64 =
            (((eval(dz_dlam4(0, 0, 0)) *
               gridtools::call<avg_i_minus_1_interval_end_plus_1_end_plus_1,
                               interval_end_plus_1_end_plus_1>::with_offsets(eval, __tmp_u_sfc_66(0, 0, 0))) *
              eval(acrlat0(0, 0, 0))) +
             ((eval(dz_dphi4(0, 0, 0)) *
               gridtools::call<avg_j_minus_1_interval_end_plus_1_end_plus_1,
                               interval_end_plus_1_end_plus_1>::with_offsets(eval, __tmp_v_sfc_67(0, 0, 0))) *
              ((gridtools::clang::float_type)1 / (gridtools::clang::float_type)6371229)));
      }

      template <typename Evaluation>
      GT_FUNCTION static void Do(Evaluation& eval, interval_start_0_end_0) {}
};

explicit parallelism keywords

After the discussion with Oli, we concluded that a statement that allows to explicitly disallow parallelism in the ij plane would be interesting as the user might write
u[i+1] += u[i]
and want a reduction but would (due to field versioning) only get a pair-wise addition.
To avoid confusion, one might implement a
#pragma noparallel {i,j,k}
and save this information as an additional field in the SIR.
A final decision on what exactly to do has not been made yet.

(from clang-gridtools #22) Add support for distinction of dimensionality of storages

Currently we only support storage and temporary_storage as arguments to stencils. It would be less error-prone to force the user the provide the dimensionality of the storage (e.g storage1d, storage2d or storage3d). Further it should be possible to have scalars as arguments.

For example, instead of

stencil foo {
  storage s1, s2, s3, scalar;
}

it seems cleaner to write

stencil foo {
  storage3d s1;
  storage2d s2;
  storage1d s3;
  var scalar;
}

given that s1 is a 3D storage, s2 a 2D and s1 a 1D.

CodeGenIntegrationTests for BoundaryConditions

Add a couple of tests that do split stencils vs not splitting them and check if correct BC's are applied

Shadowing of globals not checked

the following would be syntactically correct but is probably unintended:

globals {
 double foo;
};
stencil Test{
  var foo;
  void Do(){
    vertical_region(k_start, k_end){
      foo += 10;
    }
  }
};

syntax protection for non returning fn calls

The code below should not be legal,
there is one error printed, but a bit confusing

note: candidate stencil function not viable: requires 2 arguments, but 1 was provided

stencil_function TestFun {
  storage in;
  storage out;

  Do() {
      out = in;
  }
};

stencil Test {
  storage field_a, field_b;

  Do {
    vertical_region(k_start, k_end) {
      field_a = field_b;
      TestFun(field_a, field_b) = field_b;
    }
  }
};