How does being able to empty the model help in this case?
It helps because I may need to use the half constructed model, but
depending on the method calculations, in some cases the model will be
expanded, and in others it may be necessary or easier rebuild it from
scratch (while outside code keep references to that model).
This seems like a reasonable solution.
JuMP having an
empty! method also seems a reasonable solution to me.
In fact, implementing an
empty! method and using it just in my code,
as seems like the maintenance cost of it is too high for JuMP, is also
a reasonable solution. I could study JuMP internals, implement this
solution with little effort and little breakage of my code, and as
JuMP is below version 1.0, the API can change as much as the internals
so the breakage with JuMP is the same.
Creating variables with specific names seems fragile.
… “seems fragile”? It is or it is not. Why it would be fragile? Why
JuMP provides such feature if it is not a good idea do access the
variables this way (or is some way of accessing them, or with some
purpose, more fragile than other)? The workaround would be to create a
model wrapper structure and put the anonymous variables in a vector
there, and why this would be less fragile than using a feature that
JuMP already provides and that is widely used? One of my labs
colleagues did exactly that because he did not know about accessing
variables by name, and the first thing he did when discovered it was
to remove from his code all those useless wrappers and code keeping
them synced with the JuMP model.
It might be useful if you can point to specific code. I still don’t understand the problem that being able to call empty! resolves.
Sorry, but I will give up there. I already put a lot of effort in this
thread, my code is not a MWE and I would need to take some time to
reduce it to one, and it is basically what I already described with
prose. I am tired, and seems clear to me that solving the problem by
myself would have been more productive than asking questions and
proposing modifications in JuMP.