Backwards compatibility about ghetool

[tblanke]

I will think about it and reply at this issue with the new ideas.

[wouterpeere]

@tblanke thanks! I will create a branch for experimenting.

[wouterpeere]

Hi @tblanke , thanks for starting working on this!
I noticed a few things, which I will write down in this issue so the PR review can be made easier afterwards.

• Please update the requirements also in the README.md and the getting_started.md of the RTD
• Thanks for including the peak duration in the GUI! (I was unaware it wasn't ...) This however should only be shown in a couple of aims. I will add these link_2_show's later myself.
• Can you change this peak duration to a FloatBox instead of an IntBox?

[tblanke]

Hi @wouterpeere,

I have changed the saved file from a pickle file to a json file. So the stored data can be seen in an text editor. Furthermore, pickle files can be an security issue. Besides this allows a more flexible handling of the backward compatibility from now onwards. Of course now from version 2.1.0 to 2.1.1 it will not work.

What do you think about the new solution?

With best regards
@tblanke

[wouterpeere]

Hi @tblanke,

I think JSON is indeed a good idea. Perhaps we can even do the backwards compatibility between v2.1.0 and v2.1.1 based on the fact that it is now JSON instead of pickle? I will take a look at this possibility in the beginning of 2023. If it is too cumbersome, we can make GHEtool backwards compatible from v2.1.1 forwards.

I'll review this in the near furture!

Best,
Wouter

[wouterpeere]

Hi @tblanke,

On second thought, I don't think that JSON is a good idea. Indeed, the data can be seen in the text editor, but it will require more than 150.000 lines to display it all, due to the fact that some attributes of the Borefield object are quite long lists. The newly implemented custom_gfunction and gfunction class do also contain some long lists of data. So although it is true that one can now see the data in the text editor, I do not believe that it will be an added benefit due to the fact that this file will be extremely long.

I would suggest the following 'solution':

1. we keep the data storage for the gui in the simple pickle format
2. we create an extra functionality to the GUI to export (some) of the data to a JSON so it can be read easily.

What do you think?

Best
Wouter

[tblanke]

Hi @wouterpeere,

I think we can implement a backward compatibility from 2.1.0 to 2.1.1.
I would like to stay with JSON due to the fact that pickle can be an security issue.
We can try to reduce the size of the file by reducing the stored borefield data. Furthermore I think we can try to sort the stored data by length so it is easier to read.

Best
@tblanke

[wouterpeere]

Hi @tblanke

That sounds like a good idea. In my opinion, everything related to the stored borefield parameters can be last in the JSON, since that will not be of that much interest. This can than indeed be sorted by length. That will make everything more readable. Can you implement this?

I have some ideas on how to cope with the backward compatibility, I can implement that afterwards.

Best,
@wouterpeere

[wouterpeere]

@tblanke, on second thought, I can make a proposal on the structuring of the gui, together with some minor code restructuring. I will update you on the progress!

[wouterpeere]

Hi @tblanke

I have made some changes to the backwards compatibility:

• I made a base class for all GHEtool classes with the _to_dict and _from_dict functionality so this functions can be used recursively, which result in clearer code.
• I created a private save and load function in the gui_combine_window file. I noticed that code was duplicated between the saving of a file and saving of the backup, so I combined both into one function.
• I stored the borefield object into a separate value in the JSON (so no longer as part of the DS object). This insures that this object will be shown last in the JSON, making everything more readable.
• I added a couple of tests to increase coverage.

Please have a look at the changes and let me know if you agree with them.

Now, I will focus on

• bringing this branch up to date with the main branch
• including the compatibility between v2.1.0 and v2.1.1.

Best,
@wouterpeere

[tblanke]

Hi @wouterpeere,

Your changes looks great. I don not think we have to sort the json any further. I have fixed the compatibility between v2.1.0 and v2.1.1.

With best regards
@tblanke

[wouterpeere]

Hi @tblanke

I just saw your changes, awesome! I just altered two lines.
Have you tested this already with a stored *.GHEtool file from version 2.1.0?

Best,
@wouterpeere

[wouterpeere]

There seems to a small issue. You can replicate it like this.

• Run a calculation on v2.1.0
• Save this file
• Load with v2.1.1 (you can notice that the result page is empty, since the borefield model has been deleted due to compatibility issues)
• Run the calculation
• The numerical (text results) will not be shown, only the figure ones
• (When you change a random input value, e.g. the conductivity of the soil, and you recalculate, textresults are still not shown)
• Then you add a new scenario
• Move back to the first one, the textresults will be shown.

[tblanke]

With the new commit the results should be loaded and the small issue should also be fixed.
Have you tested this already with a stored *.GHEtool file from version 2.1.0?
Yes
Maybe next week i will find the time to create a pytest for this.

[wouterpeere]

Hi @tblanke

I think the problem is more fundamental. Since, indeed, if you know load a version v2.1.0 the results are shown, but if you then create a new scenario, calculate it, the TextResults are not shown. Only when switching to scenario 1 and back shows this TextResults. This behavior does not occur when opening a blank file.

Another way to get the same weird behavior:

• Delete the backup file
• Open the GUI (v2.1.1)
• Press calculate
• Notice that the results are displayed as expected
• Add scenario
• Press calculate again
• Notice that the text results are not shown
• Select scenario 1
• Select scenario 2
• Now the results are shown

I believe this is the same error and that it has something to do with 'checking' which add_links_2_show are relevant.

[wouterpeere]

This seems to be introduced in issue 55, last comment (d2c730d [d2c730d]), to solve a slightly different problem. I will investigate further if both problems can be solved together.

[wouterpeere]

Hi @tblanke

I think I finally found the root cause.
The problem was that, when a new scenario was added, not all links_2_be_shown were updated, when displaying the results. This was solved by calling 'check_aim_options' in display_results().

I also did some other minor changes

• Speed improvement in starting the GUI
• Solving the problem that a scenario with the same name could be created
• I rolled back the last changes in the backwards compatibility. Although, for the compatibility between v2.1.0 and v2.1.1 is does not cause any problems, the implementation was not that safe. Generally, it would be safer to discard the borefield object of a previous GHEtool version, since the functions in the borefield class could have been changed and this would cause problems when showing the results. It is safer to just discard this model and only keep the inputs of the gui, so the borefield model is correctly created when calculating the scenarios.

A pytest for the backwards compatibility would also be nice!

Best regards
@wouterpeere

[tblanke]

Hi @wouterpeere ,

I have uploaded the tests for the backward compability and the option display issue.

[wouterpeere]

Perfect, I will continue the merge!