rethink nsteps for clarity and type stability

[rafaqz]

Description

This PR makes some small changes to growth nsteps precalculation. The main reason was that it was not type-stable in Float32 because there was no way of setting the type of nsteps. Now instead of being able to set nsteps at all, (which doesn't make sense, it's precalculated for every frame)) you can use the keyword nsteps_type to set the type to Float32 if you need the performance.

Also renamed the precalc_timestep method to precalc_nsteps, as nsteps is precalculated, and the timestep is fixed.

It shouldn't be breaking syntax as no constructors should have been setting nsteps before anyway, as it did nothing.

Changes:

• [ ] New formulation/rule
• [ ] Documentation
• [x] Bug fix for existing rules (non-breaking syntax)
• [ ] Major change to existing rules (breaking syntax, needs a breaking version bump)

Checklist:

• [x] My code follows the BlueStyle style guide
• [ ] My code is commented with explanations of anything hard to understand
• [x] There are no unnecessary or unrelated code changes included in this PR
• [x] There are no depencecies added: if so, please consider if they are necessary and explain why they are required

For bugfixes

• [x] My PR addresses a single bug/connected group of bugs
• [x] I have included a test that will ensure the bug does not recur

For new Rules

• [ ] My PR is limited to a clear theme/cenceptual unit. (Otherwise make multiple PRs that can be discussed separately)
• [ ] New rules have tests in a file of the same name as the rule file, e.g. /test/newrulename.jl
• [ ] I have cited the source of the new formulation/s, if applicable
• [ ] I have added a documentation string to formulation struct/s, and added an entry in the docs

[virgile-baudrot]

Ok. I'm going to change nstep accordingly in my PR.

The link between type of element within grid and type of nstep wasn't obvious. I understand the multiplication of Float32 with Float64 would result in Float64 so you have to make sure nstep is also Float32.

Would it be simpler for the user to set something like: eltype(grid)(rule.nstep)?

Here are the check I've done to understand:

julia> a = Float32(4)
4.0f0
julia> b = Float64(4)
4.0
julia> typeof(a*b)
Float64
julia> typeof(a*eltype(a)(b))
Float32

[rafaqz]

@virgile-baudrot exactly - you would end up with Float64.

The problem is its calculated in precalcrule for multiple rules using the same method, and we don't really know what grid it will be used with at that point.

I was trying to avoid every rule that uses nsteps having to do that eltype(a)(rule.nsteps) conversion. But maybe that method is actually cleaner as the responsibility is on the package, not the user.

[rafaqz]

This actually can't work, because the grids can be other types:

eltype(grid)(rule.nstep)

So I think I'm back to the original idea now.