Fix complete ids corsica keep ids structures

@carpanes Seems pf_active.time (51 points) is the same as pf_active.coil{index_coil(1)}.current.time so if set in coil should remove from top and set homogeneous to 0. OK?

At a first glance I would say that all the currents share the same time, so we could also put homogeneous = 1 , and provide the time directly there, removing the other one. However, the field pf_active.coil{ii}.current.data and pf_active.coil{ii}.current.time was filled this way by CORSICA data originally so we might not want to change remove the original data.

Yes better keep local tim/data

I fixed most things. One question is pf_passive empty or not. Do you use something from the Corsica IDS.pf_passive?

(cannot ids_put because homogeneous not set, but should not set if empty altogether)

@carpanes I added a ids_check_empty and it seems pf_passive is empty, so I guess you do not use it?

You can check with my shot, run=1111 in my iter database or rmfield pf_passive before running liuqe

Indeed, vessel current which are the only eventual passive structure, we still don't know how to use them in ITER. Also for the case of TCV I haven't implemented yet, nor I think we are providing them to the IDS structure at the moment.

@amerle the .time in these substructure exist but are either empty or "default value". However I get an error in the ids_put:

ual_end_action: [UALBackendException = Cannot get Time information] ual_print_context: [UALLowlevelException = Cannot find context 8 in store] problems in putting data in database: Error using ids_put internal error occured with error code -1 ... in aos description_ggd/grid_ggd ... in IDS wall

What is the rule? Or may be there is no rule ? At this stage I made the parent an empty cell then it works

I don't know if it's a rule or a recommendation but yes for any array that exists you have to provide its dimensions. So for a dynamic array of structure time must be filled (or if homogeneous time is selected the base time). I think for time that is a rule. In that case it triggers an error because it is used by the backend and it can't find it (it's not an error that is linked to the mex interface particularly)

Same as always, you have to remove all unused arrays of structures before doing ids_put.

This is why for the mex I provide:

• ids_gen2 which initialises every array of structures as empty
• ids_allocate which given an ids name, a path within the ids and a size will allocate the corresponding array of structures with the correct size.

This way is more similar to the FORTRAN interface if you see what I mean.

Actually having empty structures in the ids_gen is a problem since we are adding just a few data like xxx.yyy.name and xxx.yyy.data. If we do not copy the expected substructure in yyy, then xxx.yyy has only the "name" and "data" fields and the ids_put fails.

So I cannot use something like ids_gen2, nor use the ids_get with your mex, but need the ids_gen, then copy the default structure with all expected fields in yyy then put the relevant data in yyy.name and yyy.data. What I do not do is to check that a field exists before modifying, which I should actually like isfield(xxx.yyy,'name');...

But ... that was the purpose of my second bullet with the ids_allocate part ...

OK I never tried that one hence do not know, you can do sub-allocation like:

magnetics.bpol_probe(2:N) = ids_allocate('magnetics','bpol_probe',N-1);

or something like that?

OK I just checked, indeed I can do the above. But is it standard?

Is it shared by the other MATLAB interface? no

But the plan is to phase out the other MATLAB interface, and I think this approach has advantages over the previous one so I hope no one will truly oppose it.

Since with ids_gen2, all arrays are initially empty, you would rather do something like:

magnetics.bpol_probe = ids_allocate('magnetics','bpol_probe',N);

merged