Cleaning up issues section

[reint-fischer]

Hey, I propose to clean up the issues section according to the following 4 groups:

Keep

• Fixing errors and performance filebuffer indexing of Fields #1009
• particle load balancing in parallel runs #1007
• Expanded MPI-tests to reliably cover all code #974
• Index search on skewed grid #968
• Destructors for all classes #874
• Support Global Particle ID constructors #870
• S-coordinates - issues with top and bottom cells #620
• Support sampling one Field in a SummedField list in JIT mode #587
• ctypes and pointers #560
• Parcels with ECCO4v3 native grid #548
• JIT print statements not redirected to standard out in python3 #369

Close

• Rewrite Particle loops to be over objects, instead of integers #868
• Renaming grid.time and grid.time_full #651
• Robust and efficient index search in Parcels #599

Move to discussion

• Incorporation of sgrid conventions #971
• PARCELS & Coastal NEMO applications #942
• Provide a suite of pre-manufactured Kernels and kernel functions #833
• Disentangling Parcels #618
• some comments on xarray integration #462

?

• Error when generating output file #991
• Internally compute Field derivatives #970
• Installation space #963
• Add performance advices to PARCELS page or tutorial #720
• Improving Parcels efficiency #553

Please let me know what you think, especially regarding the ones I propose to close or questionmark. Also, feel free to comment if you are involved in one of these issues.

[erikvansebille]

Thanks @reint-fischer! I agree with your list, with a few changes below

#991: Close
#970: Keep
#963: Close
#868: Keep (while @CKehl implemented this for the core Parcels code, he needs to check if this is also true for all unit tests and examples)
#720: Close (we will keep adding performance advice anyways)
#618: Keep (Disentangling Parcels is more an Issue that requires development effort than a discussion)
#560: Keep for now, but it may be that most of this is already implemented (pinging @CKehl to confirm)
#548: Move to discussion

[CKehl]

agreed with @erikvansebille 's suggestion, and move #553 to the discussions.
on #868 : yes, indeed still 'in progress', as discussed Wednesday
on #720 : disagree - leave open. That is basically how we (me and @reint-fischer ) document the cluster setup. Still, it's nice to have it in the Parcels wiki, but if we don't give advice on that for non-UU users, we'll get request on setting up things on clusters until the end of time. @reint-fischer : we should have a chat about that documentation - it was on my weekly list this week, but the other items of paper review, paper writes and EGU prep ate up nearly all the time budget.
on #618 : Keep indeed - it also connects to this 'minimally working example' for development without fieldsets or things like that. It's a 'Discussion' item.
on #560 : well, undecided. The issue suggests keeping 'persistent pointers', but that's not gonna fly with ctypes and with the way use use ndarrays. Example self.particles = np.delete(self.particles, indices) is breaking that idea right away, cause the np.delete function does not work in-place, hence returns a different array with a different pointer than put in. That said: yes, it is an issue - and yes: huge chunks of runtime are lost because of those memory copies. You can extrapolate how many similar codelines we have in parcels ... Possibly/Likely gonna be a non-issue anymore when moving to Numba at some point.