Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Edge-Case Issue with Candidate Name Processing #5

Open
tylerbarna opened this issue Aug 15, 2022 · 0 comments
Open

Edge-Case Issue with Candidate Name Processing #5

tylerbarna opened this issue Aug 15, 2022 · 0 comments
Labels
bug Something isn't working enhancement New feature or request low priority Not all that important but could be looked at

Comments

@tylerbarna
Copy link
Owner

When attempting to run the pipeline on paper candidates, I noticed that the current behavior is such that the pipeline can't process two files on the same day that represent the forced and not-forced lightcurves of one object. This is because, in the current behavior for make_jobs.py, the candname variable is generated by splitting the file name wherever an underscore is used and then defining candname to be the second element in the split list (see line 113 of make_jobs.py). This is a fairly edge-case issue, especially for daily automated runs, but it shouldn't be too hard to add something to prevent it from occurring.
@tylerbarna tylerbarna added the bug Something isn't working label Aug 15, 2022
tylerbarna added a commit that referenced this issue Aug 15, 2022
@tylerbarna
paper_candidates potential format workaround
e96e762 
I created reformatted versions of the csv files for the paper to more closely match the standard ingested format, as I noticed only one file was properly imported. I think this might have something to do with the way two of the provided csv files were formatted in that they had a different order for the data and different column labels. This *might* have something to do with the way data is processed in the nmma package (see [this function](https://github.com/nuclear-multimessenger-astronomy/nmma/blob/3f5a43c82649808af148945c0a03b6288939fd87/nmma/em/utils.py#L201)  which is referenced [here](https://github.com/nuclear-multimessenger-astronomy/nmma/blob/3f5a43c82649808af148945c0a03b6288939fd87/nmma/em/analysis.py#L471) in analysis.py), but I'd have to investigate the specific behavior in more depth.

This also exposes an issue with how candidate names for data are processed in nmma_fitter, which I have submitted as an [issue](#5). As a stopgap in this case, I've simply removed the second underscore in the formatted file

As for the actual Reformatting, I need to double check whether the correct data is being labelled as mag and mag_unc in this instance; I renamed "magpsf" to "mag" and "sigmapsf" to "mag_unc" though I'm not sure if I should be using the "magzpsci" and "magzpsciunc" columns in this instance. Additionally, these files do not contain an equivalent to limmag as far as I could identify. I've submitted it as an issue [here](#7)
@tylerbarna tylerbarna added enhancement New feature or request low priority Not all that important but could be looked at labels Aug 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working enhancement New feature or request low priority Not all that important but could be looked at
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@tylerbarna