Hi Sophie, I don't see anything wrong with your approach. If I modify the grampc_run_Sfct.c ((typeRNum*) grampc->rws->u)[0] = -1.0; /* run mpc */ grampc_run(grampc); this works fine for me. Could you maybe provide the message shown by Simulink on crashing? You can also check, that you don't change any values in u and p that are out of bounds. I can produce a crash with your code by using an expample without parameters, i.e. dim(p)=0. If you then try to change some parameter value ((typeRNum*) grampc->rws->p)[0]...
With regard to your first question. You have to change the file probfct.c, which contains the dynamics, cost functions, constraints and the corresponding derivatives. Please refer to section 3 of the manual. Regards, Felix
Hi Pierre, sorry for the late answer.... Yes, you need the previous values of the control signal. I guess your way will work. Another approach would be to directly manipulate the field which holds the control values in the grampc struct (see line 171 of startMHE.m in the CSTR example). Your states will be calculated via integration (See section 2.3 in https://link.springer.com/article/10.1007/s11081-018-9417-2?wt_mc=Internal.Event.1.SEM.ArticleAuthorOnlineFirst&utm_source=ArticleAuthorContributingOnlineFirst&utm_medium=email&utm_content=AA_en_06082018&ArticleAuthorContributingOnlineFirst_20190121)...
Hi Pierre, your approach sounds fine. You need to supply your MHE-block/probfct with your measurements. This is best done with the userparam (see the CSTR example). To be able to do change the userparam with the S-function in simulink, see https://sourceforge.net/p/grampc/discussion/general/thread/c6123760c1/ where this problem was already discussed. If you have any further questions, feel free to ask. Regards, Felix
Hi Daniel, we use an augmented Lagrangian formulation to handle equality and inequality constraints. The underlying minimization is done with a projected gradient method (see Section 3.3 in https://link.springer.com/content/pdf/10.1007%2Fs11081-018-9417-2.pdf for more details). In each iteration, the dynamics (and adjoint dynamics) are integrated over your horizon Thor with the integration scheme you chose, where the step size for Euler / Heun is equal to (Thor / (Nhor -1)). It seems your step size...
If you do it like this, your system dynamic will not be continuous. This might lead to numerical problems in the integration of your adjoint states. You didn’t write so explicitly, but I assume you also added this change to every function in your probfct-file? In addition, your predicted states 4-6 can very well be negative, since out[3] = U0; out[4] = U1; out[5] = U2; Like I wrote earlier, after changing the option LineSearchMax, I didn’t have any problems running your example (no NaNs appearing),...
Hi, it should definitely be possible, but you are not supposed to change the value of the state x from within the probfct.c. This is why all arguments besides out and userparam are constant... What you have to do, is to change the values in out[0], if x[0] is close or equal to zero. I believe your state x[3] is some kind of in/outflow for you first state, i.e. if x[0] == 0, then x[3] < 0 is not possible and the respective part in out[0] = ... should be removed? if ( (x[0] < 1e-16) && (x[3] < 0.0)...
Hi, it should definitely be possible, but you are not supposed to change the value of the state x from within the probfct.c. This is why all arguments besides out and userparam are constant... What you have to do, is to change the values in out[0], if x[0] is close or equal to zero. I believe your state x[3] is some kind of in/outflow for you first state, i.e. if x[0] == 0, then x[3] < 0 is not possible and the respective part in out[0] = ... should be removed? if ( (x[0] < 1e-16) && (x[3] < 0.0)...