IF self.entry GE 0 and self.entry LT n_elements(ponents)$
only enter loop if diagnostic is located Print, 'selecting current diagnostic: ',local turns on rest of routine if diagnostic is encountered can also be used to identify diagnostic descriptions gives the xml tag name for the desired entries My routine looked something like this: PRO read_machine_desc::startElement, URI, local, strName, attrName,$ This is where you clear and initialise any of the variables you want to use for storing information read from the xml file. Subroutine: StartElement – this is one of the main workhorses.
Subroutine: StartDocument – using this routine to clear out any instances of your pointers is a good idea, it makes sure there won’t be any conflicting variables later. Is rather important, since it tells the parser that self is to be included as a global structure which can then be referenced throughout the routine. Including this line: RETURN, self->IDLffXMLSAX::Init() I also used this to declare the diagnostic names I wanted to read out. Subroutine: init – this is where any counters or unchanging global variables are declared. Everything you define here can then later be referred to as self.whatever I kept my arrays as pointers, as the files I was reading had different array lengths, despite describing the same thing. You can use strings, floats, ints, arrays, pointers, whatever you want. Everything that will be used as a global variable must be defined here. Main – declaration of structures and variables. The simplest breakdown of the routines is something like: To start, I’ll go through the basic outline of what an xml reading routine does, the general structure (so far as I can tell, at least) and some ideas for how to solve repeating instances of variables. Of course, the real world isn’t going to be quite so simple and your xml file will most likely involve nested structures of some type. This poses a bit of an issue and takes some time to work out, since the main examples provided to read XML using IDL has only one element type to read out. One of the big issues I came across was that several of the “main” groups (such as diagnostic types, for example) all had instances of, say, r and z. It’s written as an xml file, which should make everything nice and simple. One of these standards is a machine description file, which does exactly what it says on the tin. In tokamak research, there are a large number of standards which are currently being put in place at various machines around the world. That said, it’s already proven its usefulness, so it’s probably worth it in the long run. So interesting, in fact, that it took me a little over one full working day to work out.
0 kommentar(er)
