Skip to content

Conversation

@rachel3834
Copy link
Contributor

This feature aims to improve the TOM's useability for observers operating more traditional, block-scheduled observing facilities, often manually or through remote operations. The feature provides a form and view to enable them to easily identify targets visible at their facility on the date indicated.

@rachel3834 rachel3834 added the enhancement New feature or request label Feb 12, 2024
@rachel3834 rachel3834 requested review from Fingel and jchate6 February 12, 2024 20:53
@rachel3834 rachel3834 self-assigned this Feb 12, 2024
@jchate6 jchate6 linked an issue Feb 12, 2024 that may be closed by this pull request
@phycodurus phycodurus requested review from phycodurus and removed request for phycodurus February 15, 2024 21:03
@jchate6 jchate6 added the User Issue Raised by a user label Feb 26, 2024
Copy link
Contributor

@jchate6 jchate6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've made some specific comments, that I think are important, but I have some general comments that I think will require a larger discussion.

Specifically, I'd like to talk about what you are actually looking to accomplish here. This returns a selection of targets in a list that have an airmass < 2.0 within a specific 24 hour window with 10 steps starting at YYYY-MM-DDT00:00:00 for a list of telescopes at a specific observatory. That feels like a highly specific use case that should probably be made more generalized. Users might want to change the limiting airmass, or see all of the telescopes at once, or set up their window so it encompasses a full night at CPT rather than splitting it.

Additionally, I feel like the information returned is limiting. This doesn't tell a user WHEN the target will be at it's lowest airmass, or sort them in any way or give a user an idea of how long the target will be up. Also, this is completely incompatible with non-sidereal targets.

Ultimately I'm wondering if this whole idea makes more sense being incorporated into the target list view. An airmass filter could possibly be added, and "observation planning" columns could be put on the table.

Would love to discuss further when you have time.

@rachel3834
Copy link
Contributor Author

I've implemented all of the changes requested above. I take your point about the potential for more generalized functionality for this view but I think it makes sense to implement this version first before trying to generalize.

@rachel3834 rachel3834 requested a review from jchate6 September 2, 2025 22:30
@phycodurus phycodurus removed their request for review September 3, 2025 21:28
Copy link
Contributor

@jchate6 jchate6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few things.
Mostly small. Let me know if you want to talk about the general facility module.

:alt: Target Selection table with additional columns added


Adding An Observing Facility to the Target Selection Form
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't like this section.
We really don't want people making orphaned facilities in this way.

I think we can add the basics for a DB driven general facility in a sprint.
I would recommend cutting this section and prioritizing that work in the upcoming sprint. It would be a much more sustainable way to do this, and will be necessary in the long run.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed this section, pending the other issue to add a General Facility model.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having now implemented the General Facility model, and integrated it with the target selection form, I've updated this section of the documentation accordingly.

@rachel3834
Copy link
Contributor Author

Ideally I'd like this view to present the form, plus a paginated list of results when available, but this involves combining both a FormView to handle the POST and a ListView to handle the pagination. Pushing a partial refactor with most of the comments completed in order to get advice on the best way forward.

@rachel3834
Copy link
Contributor Author

I've refactored the FormView to implement pagination on the list of targets, and updated the get and post methods so that pagination works as intended in the template.

@rachel3834 rachel3834 requested a review from jchate6 September 13, 2025 00:24
@rachel3834
Copy link
Contributor Author

I've integrated the new general facilities model with this form for calculating target visibilities from different observatories. The easiest way to handle this was to do some refactoring of the tom_observations.utils.get_sidereal_visibility function.

Copy link
Contributor

@jchate6 jchate6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pointed out a few broken or problematic changes. I haven't really gotten back into the actual utility of the feature. It seems like there is some pagination issue, but I can't really tell if that's just a symptom of other problems.

return redirect(reverse('tom_targets:list') + '?' + query_string)


class TargetGroupingView(PermissionListMixin, ListView):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused by this change.
This will break. There is no form included in the context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class has a FormView rather than a ListView.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what you mean.
A FormView requires a form, and will try to return a form class.
This view has no form. So you will get a TypeError if you try to load this page.

@rachel3834 rachel3834 requested a review from jchate6 November 19, 2025 23:29
Copy link
Contributor

@jchate6 jchate6 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry to go another round, but I think this is looking much better!
Let me know if you have any questions.

return redirect(reverse('tom_targets:list') + '?' + query_string)


class TargetGroupingView(PermissionListMixin, ListView):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand what you mean.
A FormView requires a form, and will try to return a form class.
This view has no form. So you will get a TypeError if you try to load this page.

visibiliy_intervals, airmass_max,
observation_facility=request.POST.get('observatory')
)
for site, vis_data in visibility_data.items():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works well for non-LCO facilities, but takes a very long time to load for just 100 targets at LCO and I'm not sure the table is useful.

Image

<th>{{col}}</th>
{% endfor %}
</tr>
{% if target_visibilities|length > 0 %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't make sense to be in the template after the pagination.
The pagination is happening in views, so the whole target list is being paginated, but only the visible targets are being displayed. This leads to many empty pages. Instead we should paginate the list of visible targets, removing the non-visible targets in views around line 960.

form_class = TargetSelectionForm
observable_targets = []

def get_context_data(self, *args, **kwargs):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably want to keep the form data after submitting, so it's still in the form above the table. To do this, we need to add the results of request.POST to the context data.

change this to get_context_data(self, request, *args, **kwargs):

and see other changes below.


context = super().get_context_data(*args, **kwargs)
# Surely this needs to verify that the user has permission?
context['form'] = TargetSelectionForm()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

change this to context['form'] = TargetSelectionForm(request.POST or None)

To pass the form results from a post back into the form.

telescope at the target, but it can be easily extended to add further information.

The columns of the table can be configured by editing the TOM's ``settings.py`` file.
Additional parameters can be defined for each target by adding dictionary definitions
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems confusing to me. I think we should separate the EXTRA_FIELDS conversation from the SELECTION_EXTRA_FIELDS description.

Instead, let's link them to docs/targets/target_fields.rst where they can learn how to add other fields, and then tell them how to use SELECTION_EXTRA_FIELDS


# Extract any requested extra parameters for this object, if available
for param in getattr(settings, 'SELECTION_EXTRA_FIELDS', []):
if param in target.extra_fields.keys():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also look for fields in the Target Model itself, not just target extras.
People will be adding custom Target models for exactly this purpose.

.. image:: target_selection_table_extra_fields.png
:alt: Target Selection table with additional columns added

.. code:: python
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this section sill relevant? At the very least it feels non-sequitur

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably all be included in or a reference to docs/observing/observation_module.rst

This page can be reached by adding ``/admin/`` to the end of the TOM's root URL in your browser's navigation bar, e.g.:

.. code-block:: html
> https://demo.lco.global/admin/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs a blank line and an indent.

.. code-block:: html
> https://demo.lco.global/admin/

Scrolling down the list of database tables, you will find ``Facilitys`` under the tables from the ``tom_observations`` app.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oof, no, let's fix this.

go to tom_observations.models.py

inside Facility immediately after you define the model parameters, add

class Meta:
        verbose_name_plural = "facilities"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request User Issue Raised by a user

Projects

Status: Needs Review

Development

Successfully merging this pull request may close these issues.

Classical Observing Support

3 participants