search

stfc / RegentParticleDSL

A particle-method DSL based on Regent programming language
MIT License
1 stars 0 forks source link

[BUG] zero_part/zero_config functions can't understand (multidimensional) array types #86

Closed LonelyCat124 closed 3 years ago

LonelyCat124 commented 3 years ago

At the moment it workarounds the issue by printing a WARNING in zero_config - zero_part behaviour isn't yet known.

What we can do somewhat is look for the presence of field.field.symbol_type.N - if this doesn't exist its a non-array. If it does, then we have an array.

For a 1D array type, you can build an array up from field.field.symbol_type.type.name.."["..field.field.symbol_type.N.."]"

For a 2D array type, the thing at field.field.symbol_type.type will also have a type and N defined. This can then be built up recursively I guess, since an array [A][B][C] will be in the tree in order A->B->C.

Once we have this passed back we need someway for the code to handle generating intial values for these types but I think these can be built up in some metaprogrammed way.

LonelyCat124 commented 3 years ago

It is possible to do fill([variables.config].zum, array(0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 ,0.0 ,0.0 ,0.0 ,0.0)) for an array of a known size (which they will all be).

LonelyCat124 commented 3 years ago

This is almost resolved in the latest commit - one small thing I'm unclear on if the type is int1d/bool or similar.

Looks like it works for bool but not the intxd types

LonelyCat124 commented 3 years ago

Latest commit will now work for intXd types, however its not explicit and relies on default 0 values right now.

LonelyCat124 commented 3 years ago

This is resolved for everything up to 2D arrays. Generalising this to any dimensionality I'm not sure how to do, so it'd have to be if/then/else for the generation of the arrays. I think this should cover most use cases at least.