Methods (eventually?) needed to deallocate all parameter-related arrays

[samsrabin]

In #1432, I'm adding unit tests that require reading a parameter file. Initially I made this happen at the beginning of each unit test in my test file, but that failed after the first test with "already allocated" errors on parameter-related arrays. Parameters registered with fates_parameters_type have no such problem because of its Destroy() method, but other parameters fail.

The first offending array was hydr_htftype_node in EDParamsMod (why isn't this on fates_parameters_type?), so I added a subroutine there to deallocate it.

Next I ran into a bigger problem: prt_param_type has a ton of arrays but no Destroy() method—or indeed, any method. Here are some ways I thought to resolve this:

1. Add a Destroy() method to prt_param_type with a deallocate() for every parameter array. This is a bad idea because it means the unit tests would break every time a parameter array is added or removed.
2. Add a Destroy() method to prt_param_type modeled after that in fates_parameters_type, which would require adding a bunch of other analogous methods. I don't love all the duplication in this solution.
3. Delete prt_param_type; move all parameters in prt_param_type to the fates_params object (type fates_parameters_type). There may be a good reason to keep the PARTEH parameters on a separate object, though; I see that @rgknox did it as part of PR Nutrient Enabled Aquisition (parteh pt 3) #598 but I don't know why.
4. Delete prt_param_type; make the prt_params object just another instance of fates_parameters_type.

I like 4 since it avoids duplicating the infrastructure code while still allowing PARTEH parameters to remain separate from the other FATES parameters.

For now, I'm working around this by just reading the parameter file once. However, I can imagine eventual unit tests that would want to perform multiple reads in the same test file—thus this issue.

[glemieux]

4. Delete prt_param_type; make the prt_params object just another instance of fates_parameters_type.

I like 4 since it avoids duplicating the infrastructure code while still allowing PARTEH parameters to remain separate from the other FATES parameters.

Quick idea I haven't investigated much, but maybe we have a 5th option of making prt_param_type an extension of fates_parameters_type to provide access to that Destroy() method?

[samsrabin]

What would we be extending the type with, though? If nothing, wouldn't it be simpler to just make it another instance as in 4?

[glemieux]

Per discussion at the software meeting today, the consensus seems to be go with option 3. @rgknox noted that separating the prt parameters was part of a potential future use case (i.e. adoption outside of FATES) that currently does not seem likely.

[glemieux]

What would we be extending the type with, though? If nothing, wouldn't it be simpler to just make it another instance as in 4?

I was thinking it would just including the prt specific variables assuming it was desirable to keep these parameter variables separate from the main parameters. That said, I'm not sure if that's the case from a testing design perspective.