VLASS Calculator

smyers
Posts: 29
Joined: Mon Sep 09, 2013 4:43 pm

Re: VLASS Calculator

Postby smyers » Thu Apr 03, 2014 5:43 pm

Just to be clear, the calculation of implied survey speeds (in sq.deg./hr) for a depth assume a perfect oversampled mosaic. They are calculated at band center frequency though, so if you want the depth set at the higher end (e.g. 100uJy at 18GHz rather than 13GHz) the simplest thing is to scale that to a better depth at band center as equivalent (but as someone pointed out this is spectrum specific) and keep the specification of the survey speeds (area / time) at band center. If you want something more complicated calculated I can do so but will need exact assumptions you want.

rlw@stsci.edu
Posts: 13
Joined: Mon Mar 03, 2014 6:42 pm

Re: VLASS Calculator

Postby rlw@stsci.edu » Fri Apr 04, 2014 8:58 am

smyers wrote:Just to be clear, the calculation of implied survey speeds (in sq.deg./hr) for a depth assume a perfect oversampled mosaic. They are calculated at band center frequency though, so if you want the depth set at the higher end (e.g. 100uJy at 18GHz rather than 13GHz) the simplest thing is to scale that to a better depth at band center as equivalent (but as someone pointed out this is spectrum specific) and keep the specification of the survey speeds (area / time) at band center. If you want something more complicated calculated I can do so but will need exact assumptions you want.


Thanks for the clarification, Steve. I suspected that you were not using the high frequency spacing because your sky coverage rates were higher than what I was calculating for the S-band survey.

I think it is important for all the survey science (not just Galactic) to have uniform coverage in the high-frequency IF. The problem is that the depth of the survey varies strongly with sky position if the field spacing is too wide. At the gaps in between pointings, the narrow primary beam at high frequencies means that there is effectively no sky coverage in the high-frequency IFs. The result is that the effective bandwidth varies with position in the sky. If you set the spacing at the mid-frequency, you get the full bandwidth at the field centers but a lower effective bandwidth in the gaps between fields. Coadding neighboring fields makes the mid-frequency and low-frequency noise uniform, but there still will be variable sensitivity because the bandwidth is changing with position. The effect is also spectral-index dependent, with the sensitivity varying much more strongly with position for flat or inverted spectrum sources than for steep spectrum sources.

Setting the field spacing at the highest frequency leads to uniform sky coverage at all frequencies, with the much larger field overlap at low frequencies leading to lower noise in the combined images for the low-frequency IFs. In S-band or L-band, where the frequency varies by a factor of 2 across the bandpass, each point in the sky is effectively observed 4 times at the low frequency end because the primary beam area is 4x larger there. So the rms noise in the combined image mosaic in the lowest frequency IF will be half the noise at the highest frequency IF. But the important thing is that this noise is uniform across the sky, so that the final noise map is nearly independent of spatial position.

When I calculated the effect of changing the field spacing, I found that that overall sensitivity to a typical nu**-0.7 source did not depend extremely strongly on the field spacing. If you use more closely spaced fields, it requires more pointings, but you also get to decrease the exposure time because there is more overlap at low frequencies. When you put it all together, it does take more time using the closer spacings required for high-frequency coverage, but the time doesn't increase as much as one might guess.

Does your model that computes the rms and spatial scanning rates include the effect of increased effective exposure time in the low frequency IFs compared with high frequencies? Assuming that it does, it would be really helpful to have an updated version of your sky coverage rates table that uses spacings appropriate to the high frequency end of the bandpasses.

It would also be interesting to know the effective sensitivity as a function of source spectral index. If you specify the mid-frequency flux density and spectral index, you can calculate the effective 1-sigma rms. It's always going to be higher for flatter spectra. For pointing grids that are well-sampled at the highest frequency, there's probably a fairly simple relationship between effective rms and spectral index (but I haven't worked out what that is).

smyers
Posts: 29
Joined: Mon Sep 09, 2013 4:43 pm

Re: VLASS Calculator

Postby smyers » Fri Apr 04, 2014 12:48 pm

Rick,

Again, there is no issue with spacings. The field spacing does not enter into the calculation at all. The calculation is done in the "continuous scanning" limit. Please see https://science.nrao.edu/facilities/vla ... mosaicking for details on the calculation.

If you want to set the spacing to 1/sqrt(2) of the 2.5' FWHM at 18GHz (1.77') or even finer, thats ok. You just scan a bit faster and end up with the same rms image noise. The survey speed is defined as TotalArea/TotalTime.

The key is to relate the flux density limit you want to the rms image noise for a MFS band-average image. If you want to work out what the S/N is for your source with whatever SED (e.g. a power-law spectrum with "thermal" alpha of +2.5 or whatever) you need to average that over the 12-18GHz (more or less close to the flux at band center). If detailed sensitivity matters then you might take into account what parts of the band are lost to RFI (e.g. in S-band) but I dont think we need to do that here.

RE overheads: in OTF there is minimal extra overhead if you place scan stripes a bit closer together. You lose a bit at beginning of each scan (when you move to the next one) but for large areas the scans are long on the sky so its a small part of the time. The overhead is dominated (like in single field imaging) by the time to slew to a gain calibrator every so often.

Upshot: specify the MFS image rms you need (summed over the band), thats the number we need now.

S

rlw@stsci.edu
Posts: 13
Joined: Mon Mar 03, 2014 6:42 pm

Re: VLASS Calculator

Postby rlw@stsci.edu » Sun Apr 06, 2014 12:27 pm

smyers wrote:Again, there is no issue with spacings. The field spacing does not enter into the calculation at all. The calculation is done in the "continuous scanning" limit. Please see https://science.nrao.edu/facilities/vla ... mosaicking for details on the calculation.


Thanks for helping me get this through my head. So the idea is that in the continuous scanning limit, if you want better sampling for the high frequencies, then you simply push the declination scan lines closer together and turn up the scan rate, keeping the same total integration time. That results in essentially the same rms at the low frequency end of the band (shorter integrations but more of them) while improving the uniformity on the sky at the high frequency end. Right?

I have a couple of questions about this though. S and L bands both span a factor of 2 in frequency. That means that the effective integration time at a given spot on the sky at the high frequency end of the band will be 4 times smaller than at the low frequency end due to the difference in the primary beam area. Did you take than into account in the survey speed table in your white paper? That makes computing the effective sensitivity for sources with different spectral indices more complicated. The rms is a function of frequency in these images, even if the receiver sensitivity is flat. I estimate the effective rms for source detection increases by about 50% as the spectral index goes from -2 to +1.

A more serious question is whether the OTF mode will run into integration time limitations for high-resolutions surveys. I guess you must have looked into that? For example, for a 2-4 GHz S-band OTF survey, the declination lines need to be spaced about 7.9 arcmin apart to get good sampling at 4 GHz. Your table gives a survey speed of 16.53 deg**2/hr (for 100 uJy). That implies a scan rate along the dec strips of 2.1 arcmin/s = 125 arcsec/s.

But in A-configuration the S-band resolution is about 0.9 arcsec, so this scan rate corresponds to 7 milliseconds per S-band FWHM resolution element. That means that the integration time would need to be shorter than that to avoid smearing the images in the scan direction. I figure the maximum acceptable integration time would allow the pointing to move by 0.5 FWHM synthesized beam width; that would broaden the images in the scan direction about 6%. (That might make it hard to clean bright sources and reach the desired dynamic range though, so I consider that an optimistic limit.)

Using 0.5*FWHM as the integration time, an A-configuration S-band survey that reaches 100uJy would require 3.5 msec integrations. That's way below the 50 msec integrations that are currently allowed for shared risk observing (https://science.nrao.edu/facilities/vla/docs/manuals/oss/performance/tim-res).

So are high-resolution surveys using the OTF mode going to be possible? I calculated the required integration time in msec for a 100uJy-depth survey in L, S and Ku bands:

Code: Select all

Conf  A    B    C    D
L    17    54  174  557 msec
S    3.6   11   37  117
Ku   1.7   5.5  18   57


Unless I've done something wrong, even a C-configuration S-band survey would be problematic, and a Ku-band survey at this depth requires short integrations even in D-configuration. On the timescale when we might be starting a VLASS, will the shortest integration times be significantly shorter than the current 50 msec limit?

These are not as bad for deeper surveys of course. But this does mean that one would want the single epoch observations for high-resolution deep surveys to be as long as possible, in order to reduce the slew rate and increase the integration times. That has implications for the desire of the transients people to get multiple epochs of observation.

smyers
Posts: 29
Joined: Mon Sep 09, 2013 4:43 pm

Re: VLASS Calculator

Postby smyers » Mon Apr 07, 2014 12:18 pm

First, as per a separate email discussion we had:

We actually hold the phase center constant for several integrations (we found issues when we switched phase centers faster than 1 sec). So you are not smearing across the synth beam, that would be very bad! Thats why I mentioned that faster scanning rates require faster dumps but only w.r.t the primary beam fraction you can stand. We have had good luck with 0.1-0.2xFWHM in an integration. Its a pure amplitude error so seems to be relatively benign (we are dping tests to quantify). So this is mostly a data rates issue.

Yes, the relative integration time on-sky per point will change over the band as you describe and will have to be factored into a flux density limit you want to impose. Casey and I (TWG) will see if we can come up with a simple approximate formula for sensitivity for a given alpha if you like. If needed I could do some simulations to quantify this also.

rlw@stsci.edu
Posts: 13
Joined: Mon Mar 03, 2014 6:42 pm

Re: VLASS Calculator

Postby rlw@stsci.edu » Mon Apr 07, 2014 6:35 pm

smyers wrote:We actually hold the phase center constant for several integrations (we found issues when we switched phase centers faster than 1 sec). So you are not smearing across the synth beam, that would be very bad! Thats why I mentioned that faster scanning rates require faster dumps but only w.r.t the primary beam fraction you can stand. We have had good luck with 0.1-0.2xFWHM in an integration. Its a pure amplitude error so seems to be relatively benign (we are doing tests to quantify). So this is mostly a data rates issue.


I understand this now -- since the phase center doesn't move along with the antennas, blurring at the synthesized beam (PSF) width is not an issue. The restrictions on scan rate and integration time are that (1) the phase centers need to be fixed for at least 1 second, and (2) the distance moved by the antenna pointing during that time should be less than ~0.2 of the FWHM primary beam.

Since the primary beam size is very small for Ku band, I wondered the second constraint might be a problem for the proposed Ku-band Galactic survey. Following the math for the scaling of primary beam size and the spacing of declination scan lines with frequency, I find that the scan speed in FWHM primary beams per second is

SS*(freq/1GHz)**2*(rms/100uJy)**2/1418

where SS is the survey speed in deg**2/hr to reach 100uJy (from the table in Steve's white paper) and rms is the 1-sigma noise.

Putting in the values from Steve's table but using the high-frequency end of the bandpasses to set the field sizes and spacing, I get these results:

Code: Select all

Band Freq   SS   PB-FWHM  Rate    Rate  MaxRMS
      GHz deg/hr arcmin arcmin/s  PB/s   uJy
L      2  13.90   22.5    0.88   0.039   226
S      4  16.53   11.2    2.10   0.187   104
C      6   7.21    7.5    1.37   0.183   105
Ku    18   1.45    2.5    0.83   0.331    78


PB is the primary beam FWHM (arcmin) and Rate is the scan rate required (given in both arcmin/s and primary beams/s). The requirement is for the rate in PB/s to be less than 0.2.

You can lower the scan rate by increasing the exposure time on the sky, which decreases the rms. The MaxRMS column gives the maximum rms to avoid having to scan too fast. Proposals that have target rms values higher than this in a single epoch are going to be problematic in OTF mode because they scan too fast.

The 100uJy all-sky S-band survey discussed in the extragalactic forum just fits within this requirement -- you cannot do a shallower S-band survey efficiently. If doing an S-band survey with multiple epochs, each epoch needs to be long enough to reach 100uJy rms or deeper.

On the other hand, I think a shallow Ku-band survey would not work. If you aim for a target rms of 130uJy at Ku-band (which I know was one version of the proposal), the required OTF scan rate is 1.4 arcmin/s = 0.56 primary beams per second. That appears too fast to be practical in the OTF mode. To get the scan rate down to 0.2 primary beams/s would require reducing the noise to 78uJy, which would increase the total integration time by a factor of (130/78)**2 = 2.8.

smyers
Posts: 29
Joined: Mon Sep 09, 2013 4:43 pm

Re: VLASS Calculator

Postby smyers » Mon Apr 07, 2014 7:00 pm

You don't need to keep the rate at 0.2*fwhm in 1 sec, as you can set the integration time less than that. for sband we used 0.5sec integrations and changed phase centers every 4sec. But the data rates become prohibitive the shorter you go especially in 3-bit mode over Ku-band 6GHz wide (with 2MHz channels), I wouldn't want to have to go below 0.5sec unless that were critical. We might have to do some careful testing before proposing such rates as we have had to limit bandwidth for dump times below 0.5sec.

rlw@stsci.edu
Posts: 13
Joined: Mon Mar 03, 2014 6:42 pm

Re: VLASS Calculator

Postby rlw@stsci.edu » Mon Apr 07, 2014 10:47 pm

smyers wrote:You don't need to keep the rate at 0.2*fwhm in 1 sec, as you can set the integration time less than that.

So you think the limit you mentioned above ("we found issues when we switched phase centers faster than 1 sec") doesn't apply if there are shorter integrations? I knew that shorter integrations were possible but was applying a 1 sec limit on switching the phase center based on that statement.

smyers wrote:for sband we used 0.5sec integrations and changed phase centers every 4sec. But the data rates become prohibitive the shorter you go especially in 3-bit mode over Ku-band 6GHz wide (with 2MHz channels), I wouldn't want to have to go below 0.5sec unless that were critical. We might have to do some careful testing before proposing such rates as we have had to limit bandwidth for dump times below 0.5sec.

During the telecon you said that the data rate for your survey was just below the data rate limit that Claire recommended (50 MB/s if I'm remembering the number correctly, I don't have my notes). I guess the data rate would be higher for these 3-bit Ku-band data. Do you even think that 0.5 sec would be possible in that mode? The current description in the manual says "Observations with the 3-bit (wideband) samplers must use these [default] integration times", where the default value for Ku-band is 3 sec in B/C/D and 2 sec in A. It seems like a big jump from there to integration times shorter than 0.5 sec.

Do you agree that it would not be possible to do a shallow Ku-band survey in OTF mode if the phase center switching is limited to > 1 sec? Or is there something [else] I'm missing?

claw
Posts: 26
Joined: Mon Mar 03, 2014 7:18 pm

Re: VLASS Calculator

Postby claw » Tue Apr 08, 2014 1:14 am

Regarding the frequency dependence, it sounds to me like the effective time on sky scales as the beam size. For a large survey with tight packing of scans, any point on sky will be surveyed by every part of the primary beam. If we assume a reference point at band center, all other parts of the band will have an effective time on sky that scales with the relative beam size. So:
t_int_eff ~ (nu/nu_center)**-2 and,
s_lim ~ (nu/nu_center)**-1.
Does that sound reasonable? If so, then any target sensitivity at a particular frequency can be scaled to the reference point. I suppose the ultimate s_lim would be set by the most stringent of any target sensitivity in the band. I could see this happening if some spectral lines were being targeted, but for most science cases, I imagine people can get by with a single s_lim at their frequency of choice.

casey

smyers
Posts: 29
Joined: Mon Sep 09, 2013 4:43 pm

Re: VLASS Calculator

Postby smyers » Tue Apr 08, 2014 11:15 am

rlw@stsci.edu wrote:So you think the limit you mentioned above ("we found issues when we switched phase centers faster than 1 sec") doesn't apply if there are shorter integrations? I knew that shorter integrations were possible but was applying a 1 sec limit on switching the phase center based on that statement.


AFAIK, the 1sec limit on the phase center switching applies regardless of what the integration time is set to. But that shouldn't affect things, you can set the phase center anywhere reasonably close with no problems. I think changing it ever 1-4 sec seems reasonable. You can set the integration time to anything shorter than the phase center switching scan time (there must be an integral number of integrations in each scan).

rlw@stsci.edu wrote:During the telecon you said that the data rate for your survey was just below the data rate limit that Claire recommended (50 MB/s if I'm remembering the number correctly, I don't have my notes). I guess the data rate would be higher for these 3-bit Ku-band data. Do you even think that 0.5 sec would be possible in that mode? The current description in the manual says "Observations with the 3-bit (wideband) samplers must use these [default] integration times", where the default value for Ku-band is 3 sec in B/C/D and 2 sec in A. It seems like a big jump from there to integration times shorter than 0.5 sec.


The S-band data rate for 2GHz BW and 0.5sec integrations was just under 24MB/s. A full 6GHz of BW at Ku-band will be 3x higher (72MB/s) at 0.5sec. At 1sec integrations it would be 36MB/s. Claire's suggestion was we use the 25MB/s current "soft limit" for normal observing if possible. I don't know if that will increase in 2015. But if the case were strong enough then we should ask for what is needed. In principle NRAO can purchase more archive disk space though this will be a significant cost if its a large extra volume.

rlw@stsci.edu wrote:Do you agree that it would not be possible to do a shallow Ku-band survey in OTF mode if the phase center switching is limited to > 1 sec? Or is there something [else] I'm missing?


Again its not the phase center switching that matters, but the shortest integration time we can handle. I'm reasonably comfortable with 0.5sec (we have done this), less than this will need to be tested for this bandwidth. And shorter integrations means higher data rates and volumes which would need to be strongly justified and budgeted in.


Return to “Galactic Working Group”

Who is online

Users browsing this forum: No registered users and 1 guest