avSave() action

avSave() action

Hi, I've just started learning how to use AV, and I'm playing with the supplied Fortran samples. I'm trying to understand how to control the dataset that gets stored by avSave(). In update.f90, if I insert
call avSave("zzz0.xml",status)
after
call avVisible(...)
i.e. before the loop with the avUpdate calls, and also insert
call avSave("zzz.xml",status)
after exiting the loop, I find to my surprise that zzz0.xml and zzz.xml are identical, although the data array M has been modified in the loop. My question is what determines which data get saved?

4 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

For non-allocatable arrays without the "array_visualizer" attribute, AV keeps a separate copy of all the arrays that have been loaded. When avSave is called, it is these copies that get persisted to the file. So the function of the avUpdate call is to synchronize AV's copy of the date with the calling program. The avVisible is just for display and doesn't effect how data gets saved.

The other case (allocatable arrays with the "array_visualizer" attribute), there's just one copy of the array data in shared memory. In this case, there's no need for avUpdate since there's nothing to synch.

Anyway, what you describe sounds like a bug. Are you sure the files are identical? Are the changes to the file showing up in zzz.xml if you load it in the Viewer?

Unfortunately, I don't have a copy of IVF, so I can't verify the behaviour.

John

Quoting - johnreadey
For non-allocatable arrays without the "array_visualizer" attribute, AV keeps a separate copy of all the arrays that have been loaded. When avSave is called, it is these copies that get persisted to the file. So the function of the avUpdate call is to synchronize AV's copy of the date with the calling program. The avVisible is just for display and doesn't effect how data gets saved.

The other case (allocatable arrays with the "array_visualizer" attribute), there's just one copy of the array data in shared memory. In this case, there's no need for avUpdate since there's nothing to synch.

Anyway, what you describe sounds like a bug. Are you sure the files are identical? Are the changes to the file showing up in zzz.xml if you load it in the Viewer?

Unfortunately, I don't have a copy of IVF, so I can't verify the behaviour.

John

Thanks for the useful info John. You just beat me to the punch - I came back to post that I now find that on more testing I am seeing the expected change in the .xml files. I don't know what I did wrong before, it is a very simple test. Very sorry.

Since we are talking, and you are clearly well-informed, perhaps I can trouble you with a different question. I like the 3D array viewing capability exhibited by Data/HDF5/astrojet.h5, and would like to implement something very similar in my Fortran program. I'd rather not have to delve into the xml code any more than necessary, since it is very verbose, and I'm wondering if there is an easy way to reuse it. What I'm thinking of is to first save astrojet.h5 as an xml file, then create a skeleton of that file, by cutting out the 3D data (I'm happy for now to use the palette data), and use this as a template for my data. My thought is that it might be possible to load the xml file then load the 3D data in (or vice versa) and then modify various parameters appropriately. Does this sound remotely feasible?

Do you have astrojet.h5?

Thanks
Gib

I think I've found why I was misled about the avSave() behaviour. I have discovered that if an xml file is being viewed in Array Viewer when I execute update.exe and create a new version of the xml file, the data in the file does not get overwritten, even though avSave() gives status=0, the timestamp on the file is changed, and when I go back to the original instance of Array Viewer, it tells me that the file has been changed and asks me if I want to load the new one. Since update.exe fires up Array Viewer, there are two instances of the program running, and apparently this interferes with the data writing. I'm using Windows, in case it wasn't obvious ;-).

Gib

Accedere per lasciare un commento.