-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MAGICC7 compatibility #20
Comments
Great question, backwards compatibility is not something we've done well with MAGICC before I don't think. Maintaining it will require some head scratching but it might be worth it. I guess ultimately it depends how much you want to be able to compare the two versions and how easily. Given MAGICC6 was so heavily used in AR5 I doubt people will lose interest in it anytime soon. I would obviously enjoy the ability to compare them easily (i.e. without switching environments) but I don't think this is compulsory. I also think if we don't maintain MAGICC6 compatibility then we may lose the ability to run it which could be annoying in some cases. Thoughts @lewisjared @rgieseke ? |
My view is that they are sufficiently close that the benefits of being able
to run both models using the same codebase is greater than the cost of the
added complexity. Especially if we can hide that complexity from the high
level functions.
…On Thu, 31 May 2018, 18:05 Zeb Nicholls, ***@***.***> wrote:
Great question, backwards compatibility is not something we've done well
with MAGICC before I don't think. Maintaining it will require some head
scratching but it might be worth it.
I guess ultimately it depends how much you want to be able to compare the
two versions and how easily. Given MAGICC6 was so heavily used in AR5 I
doubt people will lose interest in it anytime soon. I would obviously enjoy
the ability to compare them easily (i.e. without switching environments)
but I don't think this is compulsory. I also think if we don't maintain
MAGICC6 compatibility then we may lose the ability to run it which could be
annoying in some cases.
Thoughts @lewisjared <https://github.com/lewisjared> @rgieseke
<https://github.com/rgieseke> ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABRVwZWYwbN-UJ9H-vsX1GaxCsPfM0bTks5t36RIgaJpZM4UUiCa>
.
|
I'd agree with that
On Thu, May 31, 2018 at 10:15 AM, Jared Lewis <notifications@github.com>
wrote:
… My view is that they are sufficiently close that the benefits of being able
to run both models using the same codebase is greater than the cost of the
added complexity. Especially if we can hide that complexity from the high
level functions.
On Thu, 31 May 2018, 18:05 Zeb Nicholls, ***@***.***> wrote:
> Great question, backwards compatibility is not something we've done well
> with MAGICC before I don't think. Maintaining it will require some head
> scratching but it might be worth it.
>
> I guess ultimately it depends how much you want to be able to compare the
> two versions and how easily. Given MAGICC6 was so heavily used in AR5 I
> doubt people will lose interest in it anytime soon. I would obviously
enjoy
> the ability to compare them easily (i.e. without switching environments)
> but I don't think this is compulsory. I also think if we don't maintain
> MAGICC6 compatibility then we may lose the ability to run it which could
be
> annoying in some cases.
>
> Thoughts @lewisjared <https://github.com/lewisjared> @rgieseke
> <https://github.com/rgieseke> ?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#20 (comment)
393446794>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABRVwZWYwbN-UJ9H-
vsX1GaxCsPfM0bTks5t36RIgaJpZM4UUiCa>
> .
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AWh-m932w04rbCLrfIvmwr4DHHkBvjvIks5t36aJgaJpZM4UUiCa>
.
|
Obviously it's your project robert so I'm happy to follow your lead and
don't want to tread on toes
On Thu, May 31, 2018 at 10:16 AM, Zebedee Nicholls <
zebedee.nicholls@climate-energy-college.org> wrote:
… I'd agree with that
On Thu, May 31, 2018 at 10:15 AM, Jared Lewis ***@***.***>
wrote:
> My view is that they are sufficiently close that the benefits of being
> able
> to run both models using the same codebase is greater than the cost of the
> added complexity. Especially if we can hide that complexity from the high
> level functions.
>
> On Thu, 31 May 2018, 18:05 Zeb Nicholls, ***@***.***>
> wrote:
>
> > Great question, backwards compatibility is not something we've done well
> > with MAGICC before I don't think. Maintaining it will require some head
> > scratching but it might be worth it.
> >
> > I guess ultimately it depends how much you want to be able to compare
> the
> > two versions and how easily. Given MAGICC6 was so heavily used in AR5 I
> > doubt people will lose interest in it anytime soon. I would obviously
> enjoy
> > the ability to compare them easily (i.e. without switching environments)
> > but I don't think this is compulsory. I also think if we don't maintain
> > MAGICC6 compatibility then we may lose the ability to run it which
> could be
> > annoying in some cases.
> >
> > Thoughts @lewisjared <https://github.com/lewisjared> @rgieseke
> > <https://github.com/rgieseke> ?
> >
> > —
> > You are receiving this because you were mentioned.
> > Reply to this email directly, view it on GitHub
> > <#20
> issuecomment-393446794>,
> > or mute the thread
> > <https://github.com/notifications/unsubscribe-auth/
> ABRVwZWYwbN-UJ9H-vsX1GaxCsPfM0bTks5t36RIgaJpZM4UUiCa>
>
> > .
> >
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#20 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AWh-m932w04rbCLrfIvmwr4DHHkBvjvIks5t36aJgaJpZM4UUiCa>
> .
>
|
No, it's for everyone who wants use it (and everyone is free to fork and modify) -- I just try to keep maintainable what I'm currently maintaining :-) It seems clear that we all want and could make use of having both MAGICC6 and MAGICC7 included! |
Ok great let's go for it then |
@rgieseke can we close this? Or not until we are shipping with a MAGICC7 executable? |
I think we're sufficiently discussed and now have MAGICC7 compatibility in ... |
General question, @lewisjared @znicholls -- might be helpful for decisions on how to make design decisions.
Do we need to maintain MAGICC6 compatibility once MAGICC7 is publicly available?
Will there be a need to run both from one installation? Do you need this to run regressions tests/comparisons for MAGICC7?
One could always install version 1.x and run MAGICC6, might mean separate Virtualenvs if you actually do need both but I'd think that would be fairly rare.
The text was updated successfully, but these errors were encountered: