Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Alexander Kier Christensen
    @christensen5
    Hi all - I'm encountering a strange error with recovery kernels in Scipy mode. No matter what I put in the recovery kernel I'm getting a Kernel error with ErrorCode.Success:
    Traceback (most recent call last):
      File "/home/alexander/Documents/turbulence-patchiness-sims/tests/tests.py", line 55, in test_kernel_top_bottom_boundary
        recovery={ErrorCode.ErrorOutOfBounds: TopBottomBoundary})
      File "/home/alexander/parcels/parcels/particleset.py", line 412, in execute
        self.kernel.execute(self, endtime=time, dt=dt, recovery=recovery, output_file=output_file)
      File "/home/alexander/parcels/parcels/kernel.py", line 297, in execute
        recovery_kernel(p, self.fieldset, p.time)
      File "/home/alexander/parcels/parcels/tools/error.py", line 69, in recovery_kernel_error
        raise KernelError(particle, fieldset=fieldset, msg=msg)
    parcels.tools.error.KernelError: ErrorCode.Success
    Particle P[0](lon=5.000000, lat=5.000000, depth=-10.000000, lon=5.000000, lat=5.000000, time=0.000000, id=0.000000, depth=-10.000000, time=0.000000)
    Time: 0,    timestep dt: 1.000000
    Error:
    @christensen5 in this case the only line in my recovery kernel is particle.delete() and I'm simply calling particleset.execute with the option recovery={ErrorCode.ErrorOutOfBounds: TopBottomBoundary}
    If I change the ptype to JIT then there are no issues.
    Erik van Sebille
    @erikvansebille
    Hmm strange. Appears to be a bug. Can you create an Issue on github, with a minimal example of a code that breaks, so we can investigate?
    Alexander Kier Christensen
    @christensen5
    Will do.
    Erik van Sebille
    @erikvansebille
    Hi @christensen5 . Sorry for the long delay (been busy times finishing off the paper and code for parcels v2.0!), but I just pushed what I think is a fix to the bug you reported above. See PR #574. It might take a few days to be merged (it needs to be reviewed first), but you can of course already use that branch, if you want
    Alexander Kier Christensen
    @christensen5
    No worries! I tend to run in JIT mode so it hasn't been a real issue for me, it's just something I discovered when writing tests for my own model, and thought it worth reporting! Looking forward to reading the finished paper.
    schmidt-christina
    @schmidt-christina
    Hi all, we want to mask a specific region and then be able to detect whether we used velocities from this masked region to advect our particles. Is there a way to implement this?
    schmidt-christina
    @schmidt-christina
    I forgot to mention that I use velocities on a C-grid.
    Erik van Sebille
    @erikvansebille
    Philippe Delandmeter
    @delandmeterp
    Hi everyone,
    To implement a new fancy feature into Parcels, we’d need a better understanding of ast module of Python: https://docs.python.org/3/library/ast.html
    Anyone familiar with ast?
    phand
    @HandmannP
    Dear everybody, I just came across a very weird thing. I am reading in the nemo output fields with : parcels 2.0.0beta and when I check before all field contain the SPNA completly shown on the first attached plot, as soon as I have read the fields with the FieldSet.from_nemo The region is cut to the plot nr2 - what happens here?
    T_mask.png
    pset_with_field.png
    I need the full field?!
    Erik van Sebille
    @erikvansebille
    Hmm.. This is probably an error in the plotting routine, rather than an error in the FieldSet method itself.. What if you do a plt.imshow of your fset.U.data[0, 0, :, :]?
    phand
    @HandmannP
    By doing this the full field is available! OK great, thats then an error in the plotting and not in my fields! Thanks for the quick response Erik!
    Erik van Sebille
    @erikvansebille
    Good! An alternative solution is to add the domain keyword to the fset.U.show(). See also the last cell in https://nbviewer.jupyter.org/github/OceanParcels/parcels/blob/master/parcels/examples/tutorial_nemo_3D.ipynb
    phand
    @HandmannP
    I already tried that but got an error - as my boardes where not included in the plottet field (but certainly in the original input field) it could not find them and hence gave an error
    Erik van Sebille
    @erikvansebille
    Still, this is a bug I reckon: field.show() does not correctly determine the domain for curvilinear grids
    Strange. Can you copy-paste that error here?
    Erik van Sebille
    @erikvansebille
    Ok, I've now filed an Issue at OceanParcels/parcels#580
    phand
    @HandmannP
    I've just been running into another problem : Although defined before while running parcels with dask, during kernel built the pointers are not found and ir gives a keyerror:
    _funccode_Diff_hom_200 = inspect.getsource(_Diff_hom_200.code)
    _funcvars_Diff_hom_200 = list(_Diff_hom_200.code.co_varnames)
    KeyError: '_funccode_Diff_hom_200'
    Willi Rath
    @willirath
    The problem is that globals() on the dask worker is not necessarily the same as on the frontend. (Which is closely related to the reason why we have to get the code and variable names on the front end in the first place.)
    phand
    @HandmannP
    so it is better to directly transfer te pointer to the function i guess?
    phand
    @HandmannP
    • this is also not working... Find example in the attachment The error is : in the second file of the attachment
    phand
    @HandmannP
    I am still struggeling with this - It does not work even if the kernel is defined inside the run function.... see in the html file which is attached
    Philippe Delandmeter
    @delandmeterp
    You shouldn’t import math and random in your kernel
    math is already available
    for random, you have access to parcels random functionalities
    random.uniform, random.normalvariate, random.expovariate, ...
    See those examples of diff kernels
    phand
    @HandmannP
    So the trick was here to set the unit converters which are not set automatically - fieldset.Kx.units = parcels.tools.converters.GeographicSquared() and to rename the Kx and Ky in the definition of the Kernel to Kxx and Kyy . This works then also parallelized in dask find the example attached.
    Arianna Olivelli
    @OlivelliAri_twitter

    I am running a backwards simulation and have just got an OutOfTimeError(particle, fieldset) stating this:

    Field sampled outside time domain at time 2019-01-29T00:00:00.000000000. Try setting allow_time_extrapolation to True.

    My fieldset is extending up until 20/3/2019 so I don't really understand why that happens.

    Erik van Sebille
    @erikvansebille
    Hi @OlivelliAri_twitter. It’s tricky to figure out what happens just from this information. Can you copy/paste a notebook, like @HandmannP did above?
    Arianna Olivelli
    @OlivelliAri_twitter
    Yes, of course. The problematic date is the last day of the 'days_plus7' in the FieldCompare file.
    giselebury
    @giselebury
    Hello, I am running a code to release particles using parcels and am getting a TimeExtrapolationError: temp sampled outside domain at time -3024000. Try setting allow_time_extrapolation to True. Are you able to run parcels for ncom hourly outputs over an extended period? If so how?
    Erik van Sebille
    @erikvansebille
    Hi @giselebury, I’m not sure what time units ncom has, but in principle it should be possible. What if you don’t sample temp? Can you advect the particles in your data?