NAUG comments
- imageprofilefitter save -- DS - imfitter:=imageprofilefitter(infile='in.cm', infile2='in.mom0', axis=4); click Save: in profilefitter GUI. You now have the option to specify a text file to save spectra (vel vs. data) and fits. Only available in daily aips++ right now. 11mar04

12mar04

Additional comments -- JH 12Mar04 I'll concur with Debra's assessment of imageprofilefitter. I've done some extensive testing of the results of the fits vs. (1) AIPS SLFIT; (2) Harvy's DRAWSPEC; and (3) IDL GAUSSFIT. I found excellent agreement with all of these, with the exception that AIPS SLFIT gave errors which were about a factor of 2 too low compare to the others (interestingly, this is opposite what Walter found for errors reported by imagefitter and JMFIT). Detailed results in resolved Defect AOCso04745. I was working with a velocity cube written out from AIPS that had velocity on the 3rd axis. As we know, cubes are equal width in frequency, not velocity, so aips++ recalculates the frequency. Not exactly sure how it does this, but it doesn't give you what you want, and you have to play with the coordinate system to get the 3rd axis right for external velocity cubes (wonder if this is only a problem with velocity cubes from AIPS, or also from e.g. GMRT, ATCA, IRAM, etc?). Note that images created in aips++ do not have this problem. Comments on these are in Defect AOCso04744. As for getting the fit parameters out in a useful format, I've entered enhancment request AOCso04764 for the documentation to either link to the chapter of glish records, or give a direct example. FYI, its pretty easy to do: click "copy" in imageprofilefitter -results:=dcb.paste() -print results.fit.elements [*430=[type=GAUSSIAN, parameters=[0.010283893 860.92656 31.777157] , errors=[0.00045121694 0.68385197 1.6101082] ]] The enhancement also request that someone tell me how to access subfields in this record, e.g., something like -print results.fit.elements.parameters[0],'+/-',results.fit.elements.errors[0] If one of you know, then please tell me. John this is one of Glish's more perverse features. When a record is created where the fields are not explictly named, but just sequentially added, the field names can be very odd as you saw. However, they can always be indexed with sensible 1-based (glish is not zero based) indices r.fit.elements[1] r.fit.elements[2] etc. So I aded a little bit to the docs on this -- NK