Clean data on ModelData struct

[cguzman95]

This issue includes cleaning data of issue 111. Other data cleaned in this branch will be commented on. Some possible data to clean is the Jacobians:

Actually, in ModelData struct in phlex-common.h we have:

• J_init: Init Jacobian which saves Jacobian indices in order to fix CVODE jacobian when CVODE is reinitialized.
• J_params: Jac for sub_models
• J_rxn: Jac for reactions

And from CVODE we have J, which is the result of a linear operation with J_params and J_RXN.

The most efficient way to store data and reduce the maximum possible the global memory deserved and the complexity is:

1- J_init -> Delete and create an array of SM_INDEXVALS_S and SM_INDEXPTRS_S (There is no sense on saving an entire Jac if we don't need SM_DATA_S for example, and the sizes of this array are known from J) 2- J_param, J_rxn -> Delete and update the only J data. Seems these matrices are only used to store results from sub_model and reactions Jac calculations (without taking into account get_jac_init). So, only seems necessary to declare two auxiliar arrays on calc_jac to store these results and update J on the end.

[cguzman95]

I will check JacMap too. For the GPU, it's not good to load all the struct for only use rxn_id (see https://en.wikipedia.org/wiki/AoS_and_SoA).

As a result, I will add this to GPU milestone. I want to do this issue before adapting jac_id to the Jacobian. The reason is that, from the measurements of my master thesis, adapting the jacobian only improves the model with a 1.05-1.10 speed up, and counting now we have more data to move (rxn_env_param for example), probably it won't achieve any speedup at the moment.

[mattldawson]

Maybe we could split up ModelData (and maybe SolverData also) into smaller objects. These have both just evolved over time, and it would probably be worth trying to redesign the camp_common.h structures

[cguzman95]

Hm, it depends. For the C++ version, they will be changed for sure. They are used at the moment as a replacement for classes, so it's not so bad to have all elements of a "class" (in our case struct) in the same place instead of more "classes".

In fact, I can retrieve only rxn_id from JacMap, create a rxn_id_gpu and work with it. But It will be more mess if we change jacmap after that, so I put it in a low priority for now.

[mattldawson]

I think it's still worth spending some redesign time on this (not now, but for version 2.0) because there's a lot of repetition right now (same data structures repeated for rxns, aerosol_reps, sub_models, etc.) in ModelData. And ModelData and SolverData have somewhat specific scopes, but they are not as clear as, for example, rxns or sub models. And the way multiple grid cells are represented is sort of spread out through the ModelData elements, but I think it would be better to have a GridCell struct/class that would house all the grid-cell specific data (rxn_env_data, aero_rep_env_data, etc.) We have lots of time before version 2.0, so we could come up with some proposals for data structures and see what looks like it will work best (and apply your AoS vs SoA as appropriate).

[cguzman95]

Yep. I will tag this as a question and change the milestone to v2.0. We can return to this issue later and discuss all of this data structure stuff