Poll about fair use policy

lukas_demetz

Good morning everybody,

the last weeks have shown us a mayor increase in activity on our systems, which makes me happy, of course 😉

However, it is also beginning to show some limitations that we are running into with how we currently charge for observations. There are two areas of concern that I am currently investigating, and I would be glad to hear your opinions on them:

First issue is with fixed time plans that occupy a time, but are effectively not observable (example: coordinates are below the horizon). The issue here is that we are blocking out time that others might need. During the night, it simply would not start and other, dynamicalli scheduled requests would be able to run, so this might after all only be a temporary issue with all those Leonard imaging requests 😉
Second issue is with very short exposure times: Here the issue lies in the used telescope time, as even a 1 second frame needs several minutes of slewing, pointing updates, downloading and other stuff. The problem gets scaled up when the request is one spanning the shole night with one image taken every x minutes, effectively blocking out a significant part of the night.

So, what I am currently considering is the following:

a minimum charge of something like 30 seconds per frame, no matter how short it was.
a minimum charge applied to repeating plans of 10 minutes per repeat.

What are your thoughts? I still think that our rates are very competitive anyway, and just want to make sure that others don't get blocked out by some singular users who would also make our pockets cry 😆

poupou

lukas_demetz about fixed time... I would assume they are (timezone?) mistakes. Since both time and target are known then the imaging request web page validation should be able to notify the customer that the request is invalid (and not submit them). That would solve the "blocking out time" as well as giving the customer a chance to fix his plan.

As for short exposures setting a minimum time/fee (per frame and/or repeat) is likely the easiest way (at least coding-wise) to adjust price for a non-linear (imaging time) cost.

The other way would be to make it linear, i.e. pay for the length of the session, not for the imaging time. I'm not sure how easy it is to predict a session time but you're clearly in the business of selling scope time, not imaging time. OTOH imaging time is likely much easier to explain 😀

You might also want the "Update from the skies" to show how long each request took... that makes it easier to rationalize the price we pay versus the real cost to provide the service.

Avdhoeven

It's hard for me to say anything as I just bought my first points to try out the system. I hoped to catch some images from Leonard, but it is impossible as all times for the next weeks are already claimed. It's a pity as this is just a one time opportunity, but that's how it works and I can't make any comments as I'm new. But it maybe would be nice if there would be a database of some shared images later on? Just an idea which would be highly appreciated but I don't know if this fits in the policy. Btw compliments for the system. I'm really interested and will use it more in the future!

lukas_demetz

Hi!

Well, we are planning to gather some images of Leonard tomorrow and offer them to all of our registered users for free. I understand that many want to catch that comet, but regretfully we are unable to accomodate everybody - we would need four or five more scopes just for that 😀 But I think this might be an interesting solution for all who are interested in the comet, and hopefully will continue using our systems also in The future 🙂

Avdhoeven

lukas_demetz That's really great! I'll see if I can use my points to test something else then 🙂 Thanks for the update!

gotten

We've been using the telescopes for photometric monitoring of variable stars with a lot of short exposures (which leads to large overheads).

Ideally you would want to charge exactly for the time consumed on the telescopes, but I can imagine this is very dependent on settings (even which order filter changes occur) and therefore difficult to predict accurately in advance. So the solution with the minimum charges would work as a quick fix. It's good you are raising this point, we will shoot longer exposures with less imaging requests (which more efficient in terms of overheads) from now on.

The suggested minimum charge per exposure sounds good to me. For the other minimum charge to repeats. I'm not sure what you call a repeat in this context? Do you mean a minimum charge per imaging request, or a minimum charge for each line within an imaging request ?

For instance, would a single imaging request which shoots B,V,R filters in sequence incur 30 minutes of minimum charge, or 10 mins?

MatthiasK

gotten Just a quick question: You mention B,V,R. Which telescope has those filters?

lukas_demetz

Thanks for the replies so far.
@gotten: Yes well, it is all a bit difficult because it is also correct that not all requests are that "bad".

A repeat would be a request where you set an arbitrary number and combination of frames, and instruct the system to repeat this x times through the night, with a configurable interval between single "repeats". This is a function which is convenient for both astrometry and photometry.
Now, imagine somebody requesting a 10 second exposure of a variable star, every 20 minutes. With slewing and all overhead, whis would effectively block the scope for any request longer than about 10 minutes, which could fit in between the single repeats.

In your case, if you combine any amount of exposures in one go this would not apply 🙂

I agree that it all sonds complicated, and maybe for real photometric work with plenty of short exposures one after the other we shall find a better solution as to not penalize it. This is one of the reasons I want to discuss this openly. The easiest would be a simple "fair use" policy, where every users agrees to not try to trick the system to a disadvantage of others.

poupou

lukas_demetz hmm... I don't think anyone is trying to trick the system, even less to disadvantage others, but different needs leads to different imaging requests. Some of them might not be a good fit for the existing price structure. For that I support your suggestions and thank you for the poll to discuss this openly 😃

For myself I was [1] measuring double stars. Doing less, but longer, exposures would not help me. IOW I don't stack them, each image is measured indiviudally. I need several images (n > 10) to get a good average and error estimations. In fact longer exposures would lead to other problems: saturation and, even when not, it limits the separation between stars I can detect/measure. IOW paying more for short exposures is not an issue, but I can't really change my exposure times to pay more.

I'm missing too much data to guess the real time/impact of my requests 😅 My best data point is that I receive all emails (one per image) inside 8 minutes. The time needed before/after the emails is unknown to me [2]. Naively I thought short sessions could nicely fill small holes between longer runs and fixed-time requests.

[1] on hold until an updated pricing policy is in effect
[2] hint: session scope logs would be useful for this too :-)

lukas_demetz

poupou Well, do you have a RID so that I could check the impact your requests had? 😅

You are right, mostly it works just fine. The only ones causing trouble are repeating plans with "not enough" space between repeats. A photometric session with several short exposures one after another don't really impact much the system and here I would prefer to avoid any surcharge. Really need to evaluate the best compromise for everybody. At the end, our goal is to be able to fit as many images during one night as possible, raising the efficiency of the system and delivering possibly most requests in short term 🙂

poupou

lukas_demetz Thanks, it will help satisfy my own curiousity! My last session id was 5780 and previous ones were largely identical (but different targets).

lukas_demetz

Hi Sebastien,
oh well, your plan is alright: Plenty of short exposures back-to-back.
The only thing you could optimize with such short plans is that you could deactivate the generation of preview images, and slatesolving of every image. This saves about 25 seconds per image taken, and would speed up the imaging itself if time is critical for you 😉

rhyswynnastro

lukas_demetz This is exactly the information we need to make better plans. I'm sure everyone who uses the system would want to do it efficiently. Exposing these details would be very helpful. Maybe a hover tip over each option when configuring the plan that explains how it could have a negative impact, and/or when the setting is appropriate just like you did here would be an easy way to help guide users?

lukas_demetz

Good point.
Will work on it once I have a little more time. Very busy right now with my main job 🙂

MiVe

@Avdhoeven I was also a bit late to the party and had similar issues when looking for a time entry. I got lucky on Christmas Eve but looking at a semi failed session the 29th I have the feeling it was a close call. I was early for tonight but it looks like we had the best of comet Leonard. This will be my last entry for this comet.

Maybe besides the extra points, the amount of repeating plans at a given time for a given customer should be limited as well? This might be an issue for research purposes but will perhaps prevent a completely booked week more effectively.

Maybe it could be usefull to have access to the planning for each scope without going through the request creation wizard first. Had a weird hiccup just now while trying to view the planning. An incomplete request (coords 0,0 and arbitrary name) was submitted while clicking next instead of finish. Might have been my mouse that caused a double click, not sure 😅 Have cleaned it up.

I'm wondering what's the added value of the platesolving, validating the GoTo?

lukas_demetz

MiVe Good point about the platesolve. The newer mounts that we use (DDM85 and L-500) are very precise and we could basically disable it by default. It might be useful for astrometric purposes, as you'd end up with a platesolved fits file.

I am very busy at work right now, so any additional modifications or improvements will have to wait at least one more week. Afterwards, let's see how we can improve things. One thing that needs improvement is the calculation of the expected duration of fixed time requests, and the calendar view, for sure. Another relatively easy thing will be to offer better explanations to all the functions, and maybe the respective impacts on performance. All this got very noticeable now with the Leonard imaging, all concentraded in very little time every day 🙂

gotten

MatthiasK I mixed up the names, I was referring to the RGB filters. According to the information on the main page of the website only the CDK500 in Spain has an R filter for photometric use and the future Pro R 360 will get a BVR set.

Jose

@lukas_demetz "#p429

Hello Lukas.
It seems reasonable to me to charge a minimum of 30 seconds per shot.
Regarding repetitive shots on the same night, there are objects where this is necessary, such as short period variables or asteroids.
The issue is complex (and I have been one of the users who has done it) as it is understandable to set some limitation in order not to block the telescope all night.
One possibility, without setting an additional charge, would be to limit the time between shots to a certain value, for example 30 or 45 minutes and, if you want to do a repetition with smaller intervals, charge an additional fee.
It could also be limited in periods with no Moon and set a lower limitation in periods with a Moon larger than the crescent quarter.
Well, these are some ideas.
Best regards and thanks