Input model

simdata can use either or both of a clean component list or an image (cube) as its representation of the sky to be observed.

Component list ( complist parameter)

One way to get a component list is to deconvolve an image, and another is to create it by hand using the cl tool:

  1. dec = -46
  2. direction = "J2000 18h00m00.03s %sd0m0.0s" % dec
  3. cl.addcomponent(dir=direction, flux=1.0, freq='672.0GHz')
  4. compname = "star672GHz_dec%d.cl" % dec
  5. cl.rename(compname)
  6. cl.done()

here is a little python program makecl.py.txt that will change this ascii file my_list.txt into a componentlist

warning complist has not been as thoroughly tested as images. email rindebet at nrao.edu with questions or observations.

Image ( modelimage parameter)

You can use an image from a numerical simulation, or an actual observation - simdata makes no distinction. Note that the image represents how the sky appears to the telescope, not how the sky is presented to an observer using the telescope. In other words the image should ideally be noise-free and have infinite resolution. In practice it is usually only necessary for the input noise to be much less than the eventual output noise, and for the input resolution to be at least as sharp as the output resolution. Position and shape errors that fall within what can be resolved are also acceptable. For example a set of CLEAN components representing a galaxy will typically be discontinuous and not resemble a galaxy until it is convolved with a point spread function, but will usually work quite well as input for a simulated observation. In general you can use a deconvolution of a real observation as input for a simulation, even if you do not trust the details of the deconvolution, as long as the input noise level is acceptable.

Getting the image into CASA

simdata wants an image in CASA format or a fits file. If you have

  • a plain old grid of numbers, we recommend translating that into a fits image. You can use C, perl, IDL, IDL bound into python/casa pyIDL, or translate your idl into python with i2py
  • a fits file: the bare minimum header must have these tags
BITPIX  =                  -32 / Number of bits per data pixel 
NAXIS   =                    2 / Number of data axes 
NAXIS1  =                  100 / 
NAXIS2  =                  100 / 
  • we recommend wcstools, edhead in particular for manipulating fits headers outside of casa. CASA's imhead with mode=list or mode=summary are fine for listing the header information of either a fits or CASA image when you're inside CASA.
  • If the image has more bits per pixel than needed or wanted, iofits can be used to change the bit depth. CASA, or at least its viewer, is able to handle BITPIX=-64, so this may now be only a disk space issue.

Coordinate Systems

  • Coordinate systems are probably the most confusing part of dealing with images.
  • in a FITS file, there are header keywords that describe the World Coordinate System (WCS). the canonical papers are paperI, paperII, and paperIII. These keywords explain how to translate pixel coordinates xyz into world coordinates e.g. ra, dec, frequency. For example for the x axis, indices range from 1 to NAXIS1. index x_i corresponds in the simplest case to an RA of CRVAL1+CDELT1*(x_i-CRPIX1)
  • in CASA, an image has a CoordinateSystem attached to it, which serves the same function, translating the indices of the pixel axes into real world coordinates. The CoordinateSystem is very flexible - your pixel axes don't have to be in the same order as the World Coordinate axes for example. The motivated user can get at the CoordinateSystem by opening their image in the ia tool, and working with the ia.coordsys() object.
  • simdata will make its best attempt to turn your input image into the 4-dimensional image (RA,Dec,Stokes,Spectral) with a CoordinateSystem that it needs to calculate visibilities. If your model doesn't have polarization/Stokes information, we'll add a dummy axis to the image for you. If your image doesn't have spectral information and is jsut 2-dimensional, not a cube, we'll add a dummy spectral axis for you. If you have input that breaks it, please let me know so I can make it better remy at nrao.edu.
  • You have two basic options:
    • Specify a complete WCS in the image yourself (all pixel axes must have World Coordinates). This corresponds to the default parameter ignorecoord=False
    • Ditch whatever WCS information is in the header, or ignore the fact that you don't have any, if for example the image is from a simulation, set ignorecoord=True, and let me try to fit your data into the output parameters. simdata will then assume that your input pixel size equals the output cell size that you set, that the input spectral channel start frequency and channel width correspond to the specified output startfreq and chanwidth, and that you are providing Stokes I.
  • [*alpha alert*] modifymodel has been removed for the time being, and replaced with ignorecoord. We had issues with treating cubes properly, and reverted to the simpler "all or nothing" approach of CoordinateSystems. feedback is very welcome to rindebet at nrao.edu
  • you can scale the surface brightness of the image independently of manipulating the CoordinateSystem. set inbright to your desired Jy/pixel if you want to scale the image. (or if your model doesn't have physically sensible units to begin with).
  • If you want finer control, you can run simdata once with ignorecoord=True, and checkinputs="only" (so that it stops before the time-consuming visibility calculations), and it will produce a .coord image, with a proper WCS, which you can then tweak and use as your starting point for simulation. the imhead task with mode equal to 'put' can be used to change image header parameters.

  • Note the collection of interesting images to try simulating at Al's page - we will eventually put these into the CASA data repository so that you can have them with any CASA install.

ProtoplanetaryDisk is an example of modifying a 900 GHz image of dust to 672 GHz using CASA toolkit and taking into account a spectral index.

Topic attachments
I Attachment Action Size Date Who Comment
makecl.py.txttxt makecl.py.txt manage 658 bytes 2009-06-11 - 11:15 RemyIndebetouw  
my_list.txttxt my_list.txt manage 59 bytes 2009-06-02 - 16:28 RemyIndebetouw  
Topic revision: r17 - 2009-06-11, RemyIndebetouw
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback