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.

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

Reorganize output into logical subfolders #44

Merged
merged 9 commits into from
Feb 28, 2018
Merged

Reorganize output into logical subfolders #44

merged 9 commits into from
Feb 28, 2018

Conversation

bhazelton
Copy link
Member

@bhazelton bhazelton commented Jan 25, 2018

This branch reorganizes the output of eppsilon into the following folders:

  • ps
    • data

      • uvf_cubes
        • slices
      • kspace_cubes
        • slices
      • beams
      • 2d_binning
        • from_1d
      • 1d_binning (includes kperp/kpar files & kpar=0 files)
    • plots

      • slices
      • 2d_binning
        • from_1d
      • 1d_binning
        • bin_histograms

It is not yet backwards compatible, I have some questions about what users want for backwards compatibility. I think there are two options:

  1. When eppsilon is called on an old folder it can reorganize that folder according to this structure. If we do this, the easiest implementation will only move the files associated with the run it's called for, so if there are files generated by runs using different keyword settings, those files would not be moved until eppsilon is re-run with those settings. If this is terrible, I can try to write something that generally moves all the files, but it'll be harder. Also, I wonder whether the existing plot files should just all be deleted (since they are re-created on each run) or whether I should test for and delete only the plotfiles associated with the run it's called for.
  2. When eppsilon is called on an old folder it just leaves the existing files in place and only writes new files (and plots) to the new structure.

I'd like to get feedback from users about which of these options they prefer.
@adampbeardsley @nicholebarry @rlbyrne @mkolopanis

@bhazelton bhazelton force-pushed the reorg_output branch 2 times, most recently from e42ebd7 to f7e61a8 Compare January 25, 2018 03:55
@bhazelton bhazelton force-pushed the reorg_output branch 3 times, most recently from d947426 to db67dd5 Compare February 7, 2018 20:54
@bhazelton
Copy link
Member Author

fixes issue #19

@bhazelton bhazelton force-pushed the reorg_output branch 2 times, most recently from b5885ec to 4fd4558 Compare February 9, 2018 23:36
@rlbyrne
Copy link
Contributor

rlbyrne commented Feb 13, 2018

My vote is for 2. 1 sounds like it could get confusing fast.

@mkolopanis
Copy link
Contributor

The option 1 sounds like it would be confusing work from a development side. If a users folder is so large that option 2 causes massive bloating I think it is reasonable to assume they can handle removing files as necessary.

@adampbeardsley
Copy link
Contributor

adampbeardsley commented Feb 13, 2018

I'm in agreement with Matt and Ruby. Having a program dynamically find files and move them around makes me nervous.

@wenyang-li
Copy link

I agree with everyone upstairs. I prefer option 2 too.

@bhazelton
Copy link
Member Author

Ok, thank you all for the input. I believe I have it all working properly now, including for difference and ratio plots.

When you re-run ps_wrapper on an old folder, the DFT and power spectra should not be recalculated, but it will redo the binning (which is pretty fast). Existing files will not be moved, but any new files that are written will be written to the new locations. Files that are read but not recalculated will be left in the old location and not copied to the new location.

Difference and Ratio plots should run on any combination of new and old folders with no need to rerun anything.

I have tested it some on my own, but I'd love for some volunteers to do some real-world testing and make sure I haven't added any new bugs.

@bhazelton
Copy link
Member Author

Any objections to my merging this? @nicholebarry @rlbyrne @mkolopanis @wenyang-li @adampbeardsley

@adampbeardsley
Copy link
Contributor

adampbeardsley commented Feb 28, 2018 via email

@rlbyrne
Copy link
Contributor

rlbyrne commented Feb 28, 2018

Fine by me!

@wenyang-li
Copy link

Ditto.

@bhazelton bhazelton merged commit f6c84c6 into master Feb 28, 2018
@bhazelton bhazelton deleted the reorg_output branch February 28, 2018 21:24
@bhazelton bhazelton changed the title Do Not Merge: Reorganize output into logical subfolders Reorganize output into logical subfolders Mar 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants