Re: [arts-dev] bug or feature: metmm freq_number vs. freq_spacing
Hi Jana, Alex will commit a change to solve this issue. We decided to add some code which allows us to set default values for the frequency spacing depending on the chosen accuracy. For the fastest accuracy, the spacing will be set larger than the largest channel bandwidth. cheers, /oliver > On 4 Mar 2016, at 09:00, Oliver Lemke wrote: > > > >> On 4 Mar 2016, at 08:43, Jana Mendrok wrote: >> >> >> For ISMAR the number of frequencies for the fastest accuracy is not set to 1 >> for all channels ike for other sensors. Instead channels 10-13,19,20 are set >> to -1 which means the default frequency spacing is used instead. >> >> no, now we do definitely missunderstand each other. the ones you point out >> are channels not yet implemented. look at the other settings for them. >> plenty of question marks there. ;-) >> what i mean is e.g. happening for channel 18, which is a very broad channel. >> there the 1GHz spacing overrules the freq_number = 1 set for >> metmm_accuracy=0 and results in 5 freq points per passband. > > Ah, ok, sorry for the confusion. Got it now. Yes, that can happen. I don't > think that was intentional. We'll have to find a way to set the frequency > spacing wide enough for those cases to avoid that from happening. I'll > discuss it with Alex. > > cheers, > /oliver > ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] bug or feature: metmm freq_number vs. freq_spacing
> On 4 Mar 2016, at 08:43, Jana Mendrok wrote: > > > For ISMAR the number of frequencies for the fastest accuracy is not set to 1 > for all channels ike for other sensors. Instead channels 10-13,19,20 are set > to -1 which means the default frequency spacing is used instead. > > no, now we do definitely missunderstand each other. the ones you point out > are channels not yet implemented. look at the other settings for them. plenty > of question marks there. ;-) > what i mean is e.g. happening for channel 18, which is a very broad channel. > there the 1GHz spacing overrules the freq_number = 1 set for metmm_accuracy=0 > and results in 5 freq points per passband. Ah, ok, sorry for the confusion. Got it now. Yes, that can happen. I don't think that was intentional. We'll have to find a way to set the frequency spacing wide enough for those cases to avoid that from happening. I'll discuss it with Alex. cheers, /oliver ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] bug or feature: metmm freq_number vs. freq_spacing
Hi Jana, Now I get what you mean. :-) For ISMAR the number of frequencies for the fastest accuracy is not set to 1 for all channels like for other sensors. Instead channels 10-13,19,20 are set to -1 which means the default frequency spacing is used instead. I'll discuss that with Alex. Maybe those channels where just too inaccurate with 1 frequency? Anyway, just guessing here. We'll get back to you after discussion. Thanks for pointing this out. cheers, /oliver > On 3 Mar 2016, at 19:31, Jana Mendrok wrote: > > Hi Stefan, > > I do understand that the WSM f_gridMetMM provides the tighter of the two. > > but aren't the sensor descriptions with freq_number set depending on > metmm_accuracy levels tailor-made with respect to speed and a threshold > accuracy? why would we prepare them first to then overwrite them (e.g. > slowing down the "very very fast" setup significantly at least for ICI/ISMAR, > and occasionally forcing the f_grid to contain more points than necessary for > the intended and documented accuracy threshold)? does not really make sense > to me. > > i assumed metmm_accuracy=0 should ALWAYS setup a f_grid with exactly one grid > point per passband. the user can still overwrite this of course by > (re-)setting either of freq_number and freq_spacing. but here, we provide a > setting that overwrites itself. as written, seems odd to me. > > couldn't find this behaviour in documentation neither. the amsu-metmm report > says "The first configuration selects 1 frequency in the middle of every > channel. The second, third and fourth configuration select different numbers > of frequencies for every channel." and doesn't ever mention spacing. > > but if you're sure that's what you want, i stop complaining ;-) > wishes, > Jana > > On Thu, Mar 3, 2016 at 6:15 PM, Stefan Buehler > wrote: > Hi Jana, > > this behaviour is intentional, you are guaranteed to get a least the > frequency number and spacing you specified. The tighter constraint wins. > > Best wishes, > > Stefan > > > On 02 Mar 2016, at 14:06, Oliver Lemke wrote: > > > > Hi Jana, > > > > In general, the higher accuracy always wins. So, if the bandwidth divided > > by freq_numbers is larger than freq_spacing, the latter will be used. > > > > Whether the behaviour you see with metmm_accuracy is intentional, I leave > > to Alex to comment on. > > > > cheers, > > /oliver > > > > > >> On 2 Mar 2016, at 10:46, Jana Mendrok wrote: > >> > >> Hi, > >> > >> when running the metmm system with the provided sensor setups, i had > >> expected that the set freq_numbers (depending on metmm_accuracy choice) > >> are ruling, ie. it's always them that are applied. > >> however, i found that freq_spacing is set such that it overrules > >> freq_number occasionally (eg. several of the ISMAR channels with > >> metmm_accuracy=0, leading to 58 f_grid points for the 15 existing ISMAR > >> channels, instead of 2x15=30 I had expected). > >> > >> is this intended behaviour? or a bug? > >> > >> wishes, > >> Jana > > > > ___ > > arts_dev.mi mailing list > > arts_dev.mi@lists.uni-hamburg.de > > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi > > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi > > > > -- > = > Jana Mendrok, Ph.D. (Project Assistent) > Chalmers University of Technology > Earth and Space Sciences > SE-412 96 Gothenburg, Sweden > > Phone : +46 (0)31 772 1883 > = > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] bug or feature: metmm freq_number vs. freq_spacing
Hi Stefan, I do understand that the WSM f_gridMetMM provides the tighter of the two. but aren't the sensor descriptions with freq_number set depending on metmm_accuracy levels tailor-made with respect to speed and a threshold accuracy? why would we prepare them first to then overwrite them (e.g. slowing down the "very very fast" setup significantly at least for ICI/ISMAR, and occasionally forcing the f_grid to contain more points than necessary for the intended and documented accuracy threshold)? does not really make sense to me. i assumed metmm_accuracy=0 should ALWAYS setup a f_grid with exactly one grid point per passband. the user can still overwrite this of course by (re-)setting either of freq_number and freq_spacing. but here, we provide a setting that overwrites itself. as written, seems odd to me. couldn't find this behaviour in documentation neither. the amsu-metmm report says "The first configuration selects 1 frequency in the middle of every channel. The second, third and fourth configuration select different numbers of frequencies for every channel." and doesn't ever mention spacing. but if you're sure that's what you want, i stop complaining ;-) wishes, Jana On Thu, Mar 3, 2016 at 6:15 PM, Stefan Buehler < stefan.bueh...@uni-hamburg.de> wrote: > Hi Jana, > > this behaviour is intentional, you are guaranteed to get a least the > frequency number and spacing you specified. The tighter constraint wins. > > Best wishes, > > Stefan > > > On 02 Mar 2016, at 14:06, Oliver Lemke > wrote: > > > > Hi Jana, > > > > In general, the higher accuracy always wins. So, if the bandwidth > divided by freq_numbers is larger than freq_spacing, the latter will be > used. > > > > Whether the behaviour you see with metmm_accuracy is intentional, I > leave to Alex to comment on. > > > > cheers, > > /oliver > > > > > >> On 2 Mar 2016, at 10:46, Jana Mendrok wrote: > >> > >> Hi, > >> > >> when running the metmm system with the provided sensor setups, i had > expected that the set freq_numbers (depending on metmm_accuracy choice) are > ruling, ie. it's always them that are applied. > >> however, i found that freq_spacing is set such that it overrules > freq_number occasionally (eg. several of the ISMAR channels with > metmm_accuracy=0, leading to 58 f_grid points for the 15 existing ISMAR > channels, instead of 2x15=30 I had expected). > >> > >> is this intended behaviour? or a bug? > >> > >> wishes, > >> Jana > > > > ___ > > arts_dev.mi mailing list > > arts_dev.mi@lists.uni-hamburg.de > > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi > > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi > -- = Jana Mendrok, Ph.D. (Project Assistent) Chalmers University of Technology Earth and Space Sciences SE-412 96 Gothenburg, Sweden Phone : +46 (0)31 772 1883 = ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
Re: [arts-dev] bug or feature: metmm freq_number vs. freq_spacing
Hi Jana, this behaviour is intentional, you are guaranteed to get a least the frequency number and spacing you specified. The tighter constraint wins. Best wishes, Stefan > On 02 Mar 2016, at 14:06, Oliver Lemke wrote: > > Hi Jana, > > In general, the higher accuracy always wins. So, if the bandwidth divided by > freq_numbers is larger than freq_spacing, the latter will be used. > > Whether the behaviour you see with metmm_accuracy is intentional, I leave to > Alex to comment on. > > cheers, > /oliver > > >> On 2 Mar 2016, at 10:46, Jana Mendrok wrote: >> >> Hi, >> >> when running the metmm system with the provided sensor setups, i had >> expected that the set freq_numbers (depending on metmm_accuracy choice) are >> ruling, ie. it's always them that are applied. >> however, i found that freq_spacing is set such that it overrules freq_number >> occasionally (eg. several of the ISMAR channels with metmm_accuracy=0, >> leading to 58 f_grid points for the 15 existing ISMAR channels, instead of >> 2x15=30 I had expected). >> >> is this intended behaviour? or a bug? >> >> wishes, >> Jana > > ___ > arts_dev.mi mailing list > arts_dev.mi@lists.uni-hamburg.de > https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi ___ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
