Use MADS.jl as a backend in add-on packages

[ChrisRackauckas]

MADS.jl has some tools which would be useful for DiffEqParamEstim.jl, DiffEqSensitivity.jl, and DiffEqOptimalControl.jl. Its functionality should be wrapped so that way it can be directly used by the DiffEq ecosystem.

See madsjulia/Mads.jl#7

[ChrisRackauckas]

@finmod , since you're a user of MADS.jl, what is your opinion on the usefulness here? I tried looking into putting something together, but MADS seems to have a ton of major design flaws. Everything is built to parse files in odd ways, and it's woefully underdocumented. Do you think that there is anything actually useful to be gained from it? After taking a deep look, I think it might even be easier to re-implement some of the things it has rather than to actually use it. Though if we need to, we could build something similar to @Ayush-iitkgp link to Stan.jl, except writing out to MADS files, generating files for the returns, and reading them back. But there is no way that is ever going to not be fragile.

I think I am ready to give up on this, but would like a second opinion first.

[finmod]

Being a user of MADS is a big statement. I just ran a few exmaples and tests in Linux whereas I would have preferd Windows for testing, exploiting my CPU capabilities. Producing a new demo or prototype model is daunting. From JuliaDiffEq point of view, what is relevant is ode analysis and contaminant transport examples and within the various forms of sensitivity analysis and their graphical representation.

You are correct that this may not justify an add-on package because for many items MADS is already building on existing julia packages. The vision of JuliaDiffEq tools of analysis should be closer to AMIGO2 analysis and post-analysis with statistics and graphs/heatmaps. The information string produced in MATLAB by AMIGO2 is really nice but it should be in native Julia. Going through Stan.jl is a real possibility if the interface does not give headaches. I am willing to assess various demos of Stan.jl if you want as, so far, I have not looked at it in details. There again, native Julia should be favoured because these ins and outs to Mamba, Gadfly, Matlab etc. are almost always a pain when you seek to operate on all OS.

Robert Feldt with BlackBoxOptim opted to run post analysis in R. Perhaps you should have a look there as it looks simple enough. But BalckBoxOptim is still awaiting its upgrade to Julia 0.5 and MathProgBase interface......

[ChrisRackauckas]

Producing a new demo or prototype model is daunting.

Yes, this is what I noticed. The user interface is extremely wonky and undocumented. I think the part DiffEq could do is generate a model for MADS, but not necessarily run the MADS analysis given how directory-dependent its use/generation of files is. I'm not sure that's actually useful, given that running a MADS analysis is even less documented. Then its results seem to be less about creating a usable type to extract information from, and more or less generating end result Gadfly plots that don't have much flexibility. If we want to build toolkits, this isn't really a good solution.

So yeah, it sounds like we have similar opinions on this. I am sad it has to be this way since MADS does seem like its having a lot of work put into it but, sadly enough, it seems misguided to the point where I am not sure how useful it is (at least to other developers. Maybe to an end user, who wants exactly the functionality implemented by MADS, it's fine) given its design. I'll close this idea entirely unless I see it change.

There again, native Julia should be favoured because these ins and outs to Mamba, Gadfly, Matlab etc. are almost always a pain when you seek to operate on all OS.

Mamba.jl and Gadfly.jl are both native Julia though?

[finmod]

Yes, Gadfly.jl is native but it depends on various python packages and backends that have been the source of numerous problems in recent months. This is the way I lived it through Mads. From: Christopher Rackauckas [mailto:[email protected]] Sent: Thursday, April 6, 2017 2:22 PM To: JuliaDiffEq/DifferentialEquations.jl <[email protected]> Cc: finmod <[email protected]>; Mention <[email protected]> Subject: Re: [JuliaDiffEq/DifferentialEquations.jl] Use MADS.jl as a backend in add-on packages (#102) Producing a new demo or prototype model is daunting. Yes, this is what I noticed. The user interface is extremely wonky and undocumented. I think the part DiffEq could do is generate a model for MADS, but not necessarily run the MADS analysis given how directory-dependent its use/generation of files is. I'm not sure that's actually useful, given that running a MADS analysis is even less documented. Then its results seem to be less about creating a usable type to extract information from, and more or less generating end result Gadfly plots that don't have much flexibility. If we want to build toolkits, this isn't really a good solution. So yeah, it sounds like we have similar opinions on this. I am sad it has to be this way since MADS does seem like its having a lot of work put into it but, sadly enough, it seems misguided to the point where I am not sure how useful it is (at least to other developers. Maybe to an end user, who wants exactly the functionality implemented by MADS, it's fine) given its design. I'll close this idea entirely unless I see it change. There again, native Julia should be favoured because these ins and outs to Mamba, Gadfly, Matlab etc. are almost always a pain when you seek to operate on all OS. Mamba.jl and Gadfly.jl are both native Julia though? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#102 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AMHyIk1vLFmvkgSotGc7DsIGyVVMuX53ks5rtNjXgaJpZM4Knm4q> . <https://github.com/notifications/beacon/AMHyIplpaYb95unM9i_CBiqhYqzULVFmks5rtNjXgaJpZM4Knm4q.gif>