CASA Testing log Alpha release. S.T.Myers 16-19 October 2006 Search through this report for "NOTE" for some encountered problems and comments. running on sandrock: /home/sandrock2/smyers/Testing2/Oct06/20061016 this file: 2006-10-16-myers.txt _______________________________________________________________________________ Fire up casapy: > source /home/casa/casainit.csh /home/sandrock2/smyers/Testing2/Oct06/20061016 CASA Version 1.9 Build 1488 Hope we uprev (or reset to 0.0) soon! > casapy > execfile 'ngc5921_regression.py' This seems to have worked. Note I didn't copy the ipythonrc and matplotlibrc as suggested in the Tasking Cookbook but it seemed ok anyway (does it default to system versions of these?). Also, if I did > autocall 2 Automatic calling is: OFF suggesting that it was already set. Note that it seems to work OK if you just type "autocall" (it toggles between OFF and ON each time). What is autocall? It doesn't seem to respond to help (either at CASA or Ipython level), does show up as an Ipython internal with autocall? (but can't find anything on the Ipython wiki), but claims to not take arguments. What gives here? taskhelp seems useful, though may be painful when we get more tasks. Currently takes no arguments - could add some filtering (e.g. taskhelp 'a*') or apropos (e.g. taskhelp deconvolution) options help par gives a nice list of parameters, like taskhelp would be good to allow some apropos or filtering Try task interface, e.g. inp 'listobs', saveinputs 'listobs', etc. Note that it is unfortunate that "save" is a Magic Ipython internal. It occurs to me that it might be advantageous to make this AIPS-like task interface (with global parameters) even more AIPSified. For example, one could establish a parameter task (or taskname) that gets set with the inp command. One can then just do > inp without an argument to use this (like in AIPS) and have other commands work off this, e.g. > saveinputs and > getinputs which would do the equivalent of > execfile task+'.saved' and even > go which would be equivalent to > a = eval(task) > a _______________________________________________________________________________ Now try to replicate ALMA simulator operations. See glish script: /home/sandrock2/smyers/Testing2/Oct06/20061016/sim_demo2.g > ia.imagefromfits('GLM_34450-075_mosaic_I3.im','GLM_34450-075_mosaic_I3.fits') Seemed to work. Try to view in standalone qtviewer (its a big Spitzer image): % qtviewer& % Wed Oct 18 16:26:04 2006 NORMAL : Process 30515: waiting for read-lock on file /home/sandrock2/smyers/Testing2/20061016/Oct06/GLM_34450-075_mosaic_I3.im/table.lock What? Why does it need the read lock just to bring up a viewer???? Why doesnt it have it? If there is no other way it should time out or something. Try to do stuff in CASA: > ia.summary SEVERE image::detached: Image is detached - cannot perform operation. Hmmm, I would have expected it to have attached (equiv. to open) on the image I just made! > ia.open('GLM_34450-075_mosaic_I3.im') > ia.summary OK, that worked. > ia.close Says it detached, but no qtviewer yet. I cannot even bring up qtviewer from another directory or shell. It always seems to want to bring it up from the previous directory. NOTE: QTVIEWER SHOULD START IN WHATEVER DIRECTORY YOU INVOKE IT FROM (reported to Dave King) Try to bring it up from within CASA: > viewer 'GLM_34450-075_mosaic_I3.im' Still does not work. Same lock problem. If I exit casapy then I can bring up qtviewer. Seems to work OK. NOTE: CLOSE VIEWER DOES NOT WORK FROM Data MENU I can bring up casapy again and use ia.open etc. and still run qtviewer. But if I do ia.imagefromfits then the lock problem comes back. NOTE: ia.imagefromfits WILL NOT RELINQUISH THE READLOCK ON THE IMAGE IT MAKES (reported to Kumar) OK, sorted that, now continue testing... > ia.open('GLM_34450-075_mosaic_I3.im') > imrefx=5003; imrefy= 3346; subimsize= 400; > blcx=imrefx - pl.floor(subimsize/2); blcy=imrefy - pl.floor(subimsize/2); > trcx=blcx + subimsize - 1; trcy=blcy + subimsize - 1; Note that regions are not yet fully supported. Kumar says that you can give it a vector for rectangular boxes. > ia.subimage(outfile='GLMtest.im',region=[blcx,blcy,trcx,trcy]) This didn't work. I give up on this, just start with the subimage I made with the glish version: glmtest.modim NOTE: The reference manual is pretty poor right now. I hope it improves by February! It needs much more information and also examples for the tools. Ideally we would have someone devoted to porting and improving the tool documentation (and making task documentation). Run Python script: /home/sandrock2/smyers/Testing2/Oct06/20061016/sim_ms.py This appears to work correctly. Created ALMASIM.ms NOTE: sim also does not give up the readlock (after predict) and qtviewer hangs, but if you do > sim.close qtviewer will unhang and work ok. Use qtviewer to look at ALMASIM.ms Uh oh, all the visibilities are 0 Jy. Otherwise the viewer does a nice job. Close the ms - crash! NOTE: Closing the ms from the Data menu crashed the viewer and did a core dump > plotxy(vis='ALMASIM.ms',xaxis='uvdist',yaxis='amp') This failed horribly because of all the things set in the sim_ms.g script! Many of these are because of some badly chosen names in the script (leftover from glish), such as "start". NOTE: THERE MUST BE A MECHANISM FOR RESETTING ALL THE GLOBAL PARAMETERS (like AIPS "restore 0") AS WELL AS RESETTING DEFAULT VALUES FOR A GIVEN TASK (like AIPS "default"). Its true you can exit casapy and it reverts all parameters as far as I can tell. Ideally, setting parameters via explicit call e.g. > plotxy(vis='ALMASIM.ms',xaxis='uvdist',yaxis='amp') versus implicit call > vis='ALMASIM.ms'; xaxis='uvdist'; yaxis='amp' > plotxy would NOT set the values of the params in the former case, only in the latter. At least that was the suggestion during UIWG discussions. NOTE: Error trapping in composite tasks should be better. It should only give the first error encountered and not a whole series (e.g. if you give the wrong name as "vis" it should not then try to use the ms that it was never able to open. > start = 0 > plotxy This took about 7 minutes to plot (albeit for 14M points), even though it only reported about 43s to read and 159s to plot. Lots of disk thrashing. It seems like a memory issue with sandrock (lots of paging to disk), but it should still not do this. qtviewer was much faster for example. Just keeping the panel open seemed to lock up lots of memory. NOTE: plotxy was slow and apparently had a memory problem This vis plot looks fine, there is clearly non-zero vis! What was up with qtviewer? NOTE: qtviewer showed 0Jy for all vis, even though they were nonzero. Tried to browse table > tb.open('ALMASIM.ms') > tb.browse But it claimed not to have enough memory for the help or something like that. I had to quit stuff like qtviewer and restart casapy. Memory management should be better than this. Table does appear to have 0Jy in it for all data I could see. Further exploration showed that there was data only in the last 2 channels. Clearly a problem with sim. NOTE: My script /home/sandrock2/smyers/Testing2/Oct06/20061016/sim_ms.py produced data only in channels 6,7. I based this off Kumar's script, may be a script error (not obvious to me). Going back to the viewer showed this also. I missed it before because you need to do Adjust->Show flagged Regions...->Masked to Background to actually see the data! NOTE: Need to fix bug with qtviewer display of flagged regions etc. (known by DKing). NOTE: There seems to be inconsistent use of 0-based and 1-based numbers (e.g. for channels) in the various displays and tasks (e.g. mp/plotxy label channels 1-8 not 0-7, the viewer does it right (0-7). ----- Lets clean the image manually (if possible). We should use mosaic. > inp 'mosaic' > niter=500; gain=0.1; imsize=[256,256]; cell=[1,1] First try only 500 iterations > mosaic Oops, spwid and field were set to -1 and wanted a list. The error was: /home/casa/linux_rhe/python/2.4/mosaic.py in mosaic(vis, imagename, mode, mfalg, niter, gain, threshold, mask, nchan, start, width, step, imsize, cell, stokes, fieldid, spwid, weighting, rmode, robust, scaletype, constpb, minpb) 112 if type(spwid)==int: spwid=[spwid] 113 arg_names=['vis','imagename','mode','alg','niter','gain','threshold','mask','nchan','start','width','step','imsize','cell','stokes','fieldid','spwid','weighting','rmode','robust','scaletype','constpb','minpb'] --> 114 arg_values=[vis,imagename,mode,alg,niter,gain,threshold,mask,nchan,start,width,step,imsize,cell,stokes,fieldid,spwid,weighting,rmode,robust,scaletype,constpb,minpb] 115 arg_types=[str,str,str,str,int,float,float,list,int,int,int,int,list,list,str,list,list,str,str,float,str,float,float] Which is crazy. It should specifically say which ones were the problem, not just dump the list. NOTE: help par.fieldid should actually say that it is a list and not a number. Looking at the inp 'mosaic' doesnt say. You can do > type fieldid and it does say its a list. > imagename='ALMASIM.im' > mosaic This didnt help. That wasnt the problem. What is? Here are the inputs: > inp 'mosaic' vis = "ALMASIM.ms" imagename = "ALMASIM.im" mode = "none" alg = "mfclark" niter = 500 gain = 0.1 threshold = 0.0 mask = [''] nchan = 8 start = 0 width = 1 step = 1 imsize = [256, 256] cell = [1, 1] stokes = I fieldid = -1 spwid = -1 weighting = "natural" rmode = "none" robust = 0.0 scaletype = "NONE" constpb = 0.4 minpb = 0.1 Actually, alg='hogbom' originally, but I changed it. Looking more carefully I now see the message NameError: global name 'alg' is not defined was there. And doing mosaic? its clear that it wants "mfalg" not "alg" unlike the inp says. > mfalg='mfclark' This doesnt work of course because the problem is actually in the task definition. NOTE: mosaic incorrectly expects "mfalg" but should use "alg" --- DONE TESTING FOR NOW.