:py:mod:`gnome.weatherers.core` =============================== .. py:module:: gnome.weatherers.core Module Contents --------------- Classes ~~~~~~~ .. autoapisummary:: gnome.weatherers.core.Weatherer gnome.weatherers.core.HalfLifeWeatherer .. py:class:: Weatherer(**kwargs) Bases: :py:obj:`gnome.movers.movers.Process` Base Weathering agent. This is almost exactly like the base Mover in the way that it acts upon the model. It contains the same API as the mover as well. Not Serializable since it does is partial implementation Base weatherer class; defines the API for all weatherers Passes optional arguments to base (Process) class via super. See base class for optional arguments: `gnome.movers.mover.Process` adds 'mass_components', 'mass' to array_types since all weatherers need these. .. py:attribute:: _schema .. py:method:: __repr__() Return repr(self). .. py:method:: initialize_data(sc, num_released) Let weatherers have a way to customize the initialization of data arrays. Currently, only some weatherers use this to customize initialization of data arrays. If movers also move towards this implementation, then move to 'Process' base class. .. py:method:: prepare_for_model_run(sc) Override for weatherers so they can initialize correct 'mass_balance' key and set initial value to 0.0 .. py:method:: weather_elements(sc, time_step, model_time) Run the equivalent of get_move for weathering processes. It modifies the SpillContainer's data arrays; most weatherers update 'mass_components' and 'mass' Some objects do not implement this since they update arrays like 'area' in model_step_is_done() .. py:method:: _halflife(M_0, factors, time) Assumes our factors are half-life values .. py:method:: _exp_decay(M_0, lambda_, time) Exponential decay: x(t) = exp(lambda_*time) The `lambda_` should be 'negative' in order for function to decay .. py:method:: get_wind_speed(points, model_time, min_val=0, coord_sys='r', fill_value=1.0) Wrapper for the weatherers so they can get wind speeds .. py:method:: check_time(wind, model_time) Should have an option to extrapolate but for now we do by default TODO, FIXME: This function does not appear to be used by anything. Removing it does not break any of the unit tests. If it is not used, it should probably go away. .. py:class:: HalfLifeWeatherer(half_lives=(15.0 * 60, ), **kwargs) Bases: :py:obj:`Weatherer` Give half-life for all components and decay accordingly The half_lives are a property of HalfLifeWeatherer. If the len(half_lives) != gnome.array_types.mass_components.shape[0] then, only keep the number of elements of half_lives that equal the length of half_lives and consequently the mass_components array. The default is 5, it is possible to change default but not easily done. HalfLifeWeatherer is currently more for testing, so will change this if it becomes more widely used and there is a need for user to change default number of mass components. half_lives could be constants or could be something more complex like a function of time (not implemented yet). Not storing 'half_lives' in data_arrays since they are neither time-varying nor varying per LE. .. py:property:: half_lives .. py:attribute:: _schema .. py:method:: weather_elements(sc, time_step, model_time) weather elements over time_step