Giter Club home page Giter Club logo

dedalus's Introduction

Dedalus Project

Repo status Read the Docs PyPI - Python Version PyPI Conda Version PyPI - License

Dedalus is a flexible framework for solving partial differential equations using modern spectral methods. The code is open-source and developed by a team of researchers studying astrophysical, geophysical, and biological fluid dynamics.

Dedalus is written primarily in Python and features an easy-to-use interface with symbolic vectorial equation specification. For example, to simulate incompressible hydrodynamics in a ball, you can symbolically enter the equations, including gauge conditions and boundary conditions enforced with the tau method, as:

problem.add_equation("div(u) + tau_p = 0")
problem.add_equation("dt(u) - nu*lap(u) + grad(p) + lift(tau_u) = - u@grad(u)")
problem.add_equation("u(r=1) = 0")
problem.add_equation("integ(p) = 0")

Our numerical algorithms produce sparse and spectrally accurate discretizations of PDEs on simple domains, including Cartesian domains of any dimension, disks, annuli, spheres, spherical shells, and balls:

KdV-Burgers equation (1D IVP) Rayleigh-Benard convection (2D IVP) Periodic shear flow (2D IVP) Poisson equation (2D LBVP)
Librational instability (disk IVP) Spherical shallow water (sphere IVP) Spherical shell convection (shell IVP) Internally heated convection (ball IVP)

The resulting systems are efficiently solved using compiled libraries and are automatically parallelized using MPI. See the documentation for tutorials and additional examples.

Links

Developers

dedalus's People

Contributors

bpbrown avatar csskene avatar evanhanders avatar geoffvasil avatar hdrake avatar jayceslesar avatar jsoishi avatar kburns avatar kishore96in avatar lecoanet avatar mabdulla99 avatar maxhutch avatar navidcy avatar seclark avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

dedalus's Issues

Future does not provide abstract meta_* methods

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).

The original report had attachments: mwe_attr_err.py


When constructing objects like operators that inherit from Future, one needs to specify all of the possible metadata types as classes. As of right now, there are no abstract methods for these. As a result, when one creates a new Operator that is also FutureField, if you do not know to add meta_parity (for example), you will get a very obscure error, because Dedalus will attempt to resolve meta_parity in UnaryGridFunctions.

This is very hard to track down, and would be greatly eased if Future provided abstract (but not implemented) methods for all possible metadata attributes on incoming fields. Then, at least one would know what to add.

Can't use variable 'H'

Original report (archived issue) by Jhett Bordwell (Bitbucket: jhbordwell).


In attempting to automatically generate a large number of equations to explore an extended chemical network, I ran into an interesting bug. When 'H' is used as a variable, I received the following error upon including an "exp(H)" term in my equation,

*** AttributeError: 'function' object has no attribute 'exp'

I checked if this occurs for any other letter of the alphabet, and it does not.

flowtools.CFL.compute_dt() returning AttributeError when cadence=1

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


Commit 543424f0c61d appears to break flowtools.CFL.compute_dt() when the CFL cadence=1. To reproduce this, edit dedalus/examples/ivp/2d_rayleigh_benard.py and change cadence=1, then run the script.

Doing so will reproduce the following error:

Traceback (most recent call last):
  File "rayleigh_benard.py", line 111, in <module>
    dt = CFL.compute_dt()
  File "/home5/bpbrown/dedalus/src/dedalus/dedalus/extras/flow_tools.py", line 203, in compute_dt
    max_global_freq = self.reducer.global_max(local_freqs)
  File "/home5/bpbrown/dedalus/src/dedalus/dedalus/extras/flow_tools.py", line 51, in global_max
    if data.size:
AttributeError: 'int' object has no attribute 'size'

This error does not occur when CFL cadence>1.

Commit 3c591a74b7d2 has the correct expected behaviour for CFL compute_dt().

Error does not make sense for using BCs with a fully Fourier domain

Original report (archived issue) by Jhett Bordwell (Bitbucket: jhbordwell).


The error message that you receive when using BCs with a fully Fourier domain is probably not the most helpful. While there is a helpful message given in pencils.py (L90), another error is raised first. Instead of receiving a message about not setting boundary conditions, you receive, "LHS operator {} is coupled along direction {}" from operators.py (L1185).

plot_operator no longer works

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).


The plot_operator no longer properly draws a graph of operator trees. Using the example in the example notebook, this

#!python
add_op = 10 + f
tree_op = 2*add_op + f*f
from dedalus.tools.plot_op import plot_operator
plot_operator(tree_op, figsize=8, fontsize=12)

now draws a single bubble with the entire expression in it.

Documentation

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).


We need to begin documenting the code as soon as its API (and rough internal structure) becomes stable. That time is coming soon.

Example notebooks 2 and3 don't work

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).


The example notebooks in the documentation repository do not work with the tip of dedalus. Notebook 2 does not work because the dedalus-project/dedalus_extras repository is currently empty. Notebook 3 fails because pencil building fails on transverse Fourier bases:

solver = de.solvers.IVP(problem, domain, de.timesteppers.SBDF2)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-11-88eff79b98e1> in <module>()
----> 1 solver = de.solvers.IVP(problem, domain, de.timesteppers.SBDF2)

/home/jsoishi/hg-projects/dedalus2/dedalus2/pde/solvers.py in __init__(self, problem, domain, timestepper)
    132         write_progress = (domain.distributor.rank == 0)
    133         for p in progress(pencils, desc='Building pencil matrices (rank 0):', write=write_progress, bar=False):
--> 134             p.build_matrices(problem, primary_basis)
    135 
    136         # Build systems

/home/jsoishi/hg-projects/dedalus2/dedalus2/data/pencil.py in build_matrices(self, problem, basis)
    165         # Start G_bc with integral term, since the Int matrix is always defined
    166         self.G_eq = F * kron(basis.Pre, Se)
--> 167         self.G_bc = kron(basis.Int, Si)
    168         if Sl.any():
    169             self.G_bc = self.G_bc + kron(basis.Left, Sl)

/home/jsoishi/build/lib/python3.3/site-packages/scipy/sparse/construct.py in kron(A, B, format)
    299 
    300     """
--> 301     B = coo_matrix(B)
    302 
    303     if (format is None or format == "bsr") and 2*B.nnz >= B.shape[0] * B.shape[1]:

/home/jsoishi/build/lib/python3.3/site-packages/scipy/sparse/coo.py in __init__(self, arg1, shape, dtype, copy)
    182                     raise TypeError('expected rank <= 2 array or matrix')
    183 
--> 184                 self.shape = M.shape
    185                 self.row, self.col = M.nonzero()
    186                 self.data  = M[self.row, self.col]

/home/jsoishi/build/lib/python3.3/site-packages/scipy/sparse/base.py in set_shape(self, shape)
     72 
     73         if not (shape[0] >= 1 and shape[1] >= 1):
---> 74             raise ValueError('invalid shape')
     75 
     76         if (self._shape != shape) and (self._shape is not None):

ValueError: invalid shape

Importing dedalus causes lots of CPU to be used

Original report (archived issue) by Stephen Biggs-Fox (Bitbucket: stephen-biggs-fox).


When I import dedalus (e.g. import dedalus.public as de) my CPU usage suddenly goes way up (>50%) and stays up. In contrast, importing other python modules, e.g. numpy, barely increases the CPU usage at all (~2%) and it quickly drops back to zero anyway. I have only tested this on my own laptop but this happens in the python terminal, ipython and jupyter notebooks, i.e. not a notebook / ipython compatibility issue. Currently trying to install elsewhere to see if the same issue occurs. This is major as it is preventing me from using dedalus safely (I can literally feel my laptop overheating and al I've done is import).

Add verbose flag to ok() in integrator.py to suppress output?

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


Would it be useful to add a verbosity flag to ok() in integrator.py to optionally suppress text output?

This has come up in the advection diffusion test, where I'm using

#!python
for a in a_array:
     for b in b_array:
            while int.ok:
                  # testing loop goes here

to loop a test over a parameter space in a,b. The side-effect is that extraneous "Stop iteration reached." messages confuse the test outputs.

No documentation on running tests and manually importing tests fails

Original report (archived issue) by Ashwin Vishnu (Bitbucket: avmo).


  • I cannot find any mention of how to run tests:

https://dedalus-project.readthedocs.io/en/latest/search.html?q=test&check_keywords=yes&area=default#

I tried the most obvious ones: unittest, pytest, nose - none of them detected any tests.

  • Even if I wish to run it interactively do them in a console that doesn't work either
In [1]: from dedalus.tests.special_functions import airy
---------------------------------------------------------------------------
ModuleNotFoundError                       Traceback (most recent call last)
<ipython-input-1-89f2b31b55a4> in <module>()
----> 1 from dedalus.tests.special_functions import airy

ModuleNotFoundError: No module named 'dedalus.tests'

In [3]: import dedalus

In [4]: dir(dedalus)
Out[4]: 
['__builtins__',
 '__cached__',
 '__doc__',
 '__file__',
 '__loader__',
 '__name__',
 '__package__',
 '__path__',
 '__spec__']

In [5]: from dedalus.
                      core                   libraries              dedalus.__hg_version__ 
                      dev                    public                                        
                      extras                 tools                                         

Documentation should include commit policies

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).


Given our recent issue where we accidentally PR'd a branch, requiring a graft/strip operation on everyone, we should write a document outlining our development practices. This will bring more openness to our development community.

Truncation details

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


We should do some quantitative investigation into the details of truncation (i.e. truncating the system before vs after preconditioning).

Intel build environment squashing locale settings

Original report (archived issue) by Max Hutchinson (Bitbucket: maxhutch).


I'm trying to build on my workstation and can't get past this issue:

#!bash

icc: command line warning #10006: ignoring unknown option '-fwrapv'
Catastrophic error: could not set locale "" to allow processing of multibyte characters

Which is weird, because if I manually execute the offending compile command, it throws some warnings but completes compilation. I've included both commands below.

It seems like the python compile environment is suppressing the LANG environment variable, which others have pointed to as the source of this type of error. In my shell, it is set:


maxhutch@edoras:~/src/dedalus2$ env | grep LANG
LANG=en_US.UTF-8

Configuration

  • Debian Wheezy
  • Intel 14.0.1
  • Fresh (today) anaconda3 environment, with only dedalus installation directions followed
  • OpenMPI 1.6.5
#!bash

maxhutch@edoras:~/src/dedalus2$ ~/anaconda3/bin/python3 setup.py build_ext --inplaceLooking for fftw prefix
  Found env var FFTW_PATH = /opt/fftw3/
Looking for mpi prefix
  Found env var MPI_PATH = /opt/openmpi/
Looking for fftw prefix
  Found env var FFTW_PATH = /opt/fftw3/
running build_ext
building 'dedalus2.libraries.fftw.fftw_wrappers' extension
icc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -Idedalus2/libraries/fftw/ -I/home/maxhutch/anaconda3/lib/python3.4/site-packages/numpy/core/include -I/home/maxhutch/anaconda3/lib/python3.4/site-packages/mpi4py/include -I/opt/fftw3/include -I/opt/openmpi/include -I/home/maxhutch/anaconda3/include/python3.4m -c dedalus2/libraries/fftw/fftw_wrappers.c -o build/temp.linux-x86_64-3.4/dedalus2/libraries/fftw/fftw_wrappers.o
icc: command line warning #10006: ignoring unknown option '-fwrapv'
Catastrophic error: could not set locale "" to allow processing of multibyte characters

compilation aborted for dedalus2/libraries/fftw/fftw_wrappers.c (code 4)
error: command 'icc' failed with exit status 4
maxhutch@edoras:~/src/dedalus2$ icc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -Idedalus2/libraries/fftw/ -I/home/maxhutch/anaconda3/lib/python3.4/site-packages/numpy/core/include -I/home/maxhutch/anaconda3/lib/python3.4/site-packages/mpi4py/include -I/opt/fftw3/include -I/opt/openmpi/include -I/home/maxhutch/anaconda3/include/python3.4m -c dedalus2/libraries/fftw/fftw_wrappers.c -o build/temp.linux-x86_64-3.4/dedalus2/libraries/fftw/fftw_wrappers.o
icc: command line warning #10006: ignoring unknown option '-fwrapv'
In file included from /home/maxhutch/anaconda3/lib/python3.4/site-packages/numpy/core/include/numpy/ndarraytypes.h(1804),
                 from /home/maxhutch/anaconda3/lib/python3.4/site-packages/numpy/core/include/numpy/ndarrayobject.h(17),
                 from /home/maxhutch/anaconda3/lib/python3.4/site-packages/numpy/core/include/numpy/arrayobject.h(4),
                 from dedalus2/libraries/fftw/fftw_wrappers.c(232):
/home/maxhutch/anaconda3/lib/python3.4/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h(15): warning #1224: #warning directive: "Using deprecated NumPy API, disable it by "          "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
  #warning "Using deprecated NumPy API, disable it by " \
   ^

dedalus2/libraries/fftw/fftw_wrappers.c(6509): warning #167: argument of type "int *" is incompatible with parameter of type "const fftw_r2r_kind={enum fftw_r2r_kind_do_not_use_me} *"
    __pyx_v_self->forward_plan = fftw_plan_guru_r2r(__pyx_v_trans_rank, __pyx_v_trans_struct, __pyx_v_vec_rank, __pyx_v_vec_struct_f, __pyx_v_gdata, __pyx_v_cdata, __pyx_v_kind, (__pyx_v_intflags | __pyx_e_8dedalus2_9libraries_4fftw_10fftw_c_api_FFTW_DESTROY_INPUT));
                                                                                                                                                                    ^

dedalus2/libraries/fftw/fftw_wrappers.c(6518): warning #167: argument of type "int *" is incompatible with parameter of type "const fftw_r2r_kind={enum fftw_r2r_kind_do_not_use_me} *"
    __pyx_v_self->backward_plan = fftw_plan_guru_r2r(__pyx_v_trans_rank, __pyx_v_trans_struct, __pyx_v_vec_rank, __pyx_v_vec_struct_b, __pyx_v_cdata, __pyx_v_gdata, __pyx_v_kind, (__pyx_v_intflags | __pyx_e_8dedalus2_9libraries_4fftw_10fftw_c_api_FFTW_DESTROY_INPUT));
                                                                                                                                                                     ^

dedalus2/libraries/fftw/fftw_wrappers.c(8016): warning #167: argument of type "int *" is incompatible with parameter of type "const fftw_r2r_kind={enum fftw_r2r_kind_do_not_use_me} *"
    __pyx_v_self->forward_plan = fftw_plan_guru_r2r(__pyx_v_trans_rank, __pyx_v_trans_struct, __pyx_v_vec_rank, __pyx_v_vec_struct_f, __pyx_v_gdata, __pyx_v_cdata, __pyx_v_kind, (__pyx_v_intflags | __pyx_e_8dedalus2_9libraries_4fftw_10fftw_c_api_FFTW_DESTROY_INPUT));
                                                                                                                                                                    ^

dedalus2/libraries/fftw/fftw_wrappers.c(8025): warning #167: argument of type "int *" is incompatible with parameter of type "const fftw_r2r_kind={enum fftw_r2r_kind_do_not_use_me} *"
    __pyx_v_self->backward_plan = fftw_plan_guru_r2r(__pyx_v_trans_rank, __pyx_v_trans_struct, __pyx_v_vec_rank, __pyx_v_vec_struct_b, __pyx_v_cdata, __pyx_v_gdata, __pyx_v_kind, (__pyx_v_intflags | __pyx_e_8dedalus2_9libraries_4fftw_10fftw_c_api_FFTW_DESTROY_INPUT));
                                                                                                                                                                     ^

maxhutch@edoras:~/src/dedalus2$ 

Dedalus hangs in parallel when attempting a 3D interpolation using a Chebyshev basis

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).

The original report had attachments: interpolation_test.py


If one attempts to perform an interpolation to a single point in 3D before the transposes are created, Dedalus will hang if one of the bases is Chebyshev.

A workaround is to force the transposes to be created before the interpolation, for example by doing

data['c']
data['g']

The attached script provides a minimal working example. It runs fine in serial, but hangs in parallel if the workaround remains commented out.

Other notes:

  • the bug does not manifest if interpolation is done along only one dimension (even if it is the Chebyshev dimension)
  • This problem occurs in practice if one wishes to drop a "probe" in the flow to get a field at a given point and output it to a high time-cadence analysis task. The simulation will hang if the analysis task is triggered before the first timestep (as it is by default)

Check form of eigenvalue and boundary-value problems

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


We should check whether the RHS of problems passed to the LinearEigenvalue and LinearBVP solvers meet the requirements/assumptions of those solvers:

-For eigenvalue problems, the RHS must be 0

-For BVPs, the RHS can contain inhomogeneous terms, but shouldn't have any terms involving the fields. (Note: a nonlinear BVP solver is also on the to-do list).

EVP should be able to automatically set RHS to zero

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


It would be nice to be able to do EVP problems on some of our fully non-linear equation sets. Right now, this does not seem to be feasible without significantly modifying the equations (explicitly setting the RHS to zero). This may not be desirable, if you want to make sure that say linear stability analysis via EVP and nonlinear behaviour studies via IVP are one-to-one.

It would be nice if EVP could take an optional keyword which goes in and zeros out the RHS for a set of equations within EVP only. Then the same equation set could be used for both EVPs and IVPs, with modification only at the problem instantiation level. This should be an optional keyword (with default value False) so that the user needs to explicitly select that this behaviour should occur.

This could eliminate a class of errors where mistakes in the EVP equations are fixed but are not correctly propagated to the corresponding IVP equations.

This capability does not appear to be present in problems.py.

boundary condition encapsulation

Original report (archived issue) by Geoffrey Vasil (Bitbucket: gvasil).


need to include boundary conditions into M, L, F framework. Some boundary conditions take the form of time-stepped equations. e.g, QG, free-surfaces. This will allow for simple solve at the end of timestepper.py.

100% CPU usage when dedalus is imported into an interactive shell

Original report (archived issue) by Josh Burkart (Bitbucket: joshburkart).


Hi guys! Dedalus is a really great package; I've been playing around with it for some side projects.

One issue I've encountered is that if I load dedalus into an interactive shell (Python, IPython, or IPython notebook), even if I'm not doing anything with it I notice the associated python executable using 100% of one CPU. E.g.:

$ ipython
In [1]: import dedalus.public

# In another terminal window...
$ top
...
96028  python       99.6  00:22.26 4/1   0    27    59M    0B     0B     96027 96027 running
...

I'm on Mac OSX El Capitan with Anaconda Python 3.5. Can anyone else reproduce this? Thanks!

Move main branch & stack to mpi4py >= 2.0.0

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


I motion that it's time to move the stack (and dedalus mpi wrappers) to mpi4py >= 2.0.0. We've held off on this because of an api change in mpi4py between versions 1.3.1 and 2.0.0.

@jsoishi has a nice patch for the change to the mpi variables, and mpi-sgi (NASA/Pleaides preferred compilers) require mpi4py >= 2.0.0. I say let's incorporate Jeff's patch into the main branch, update the stack requirements, and move on.

bz2 missing from dependencies list for debian in install.sh

Original report (archived issue) by Stephen Biggs-Fox (Bitbucket: stephen-biggs-fox).


As the title suggests, bz2 is missing from the dependencies list for debian in the install.sh script. That is, it currently says the following (line 358-381) but the items in bold are missing and need to be added. Without this, one cannot import matplotlib!

Looks like you're on a Debian-compatible machine.

You need to have these packages installed:

  • libbz2-dev

  • libatlas-base-dev

  • mercurial

  • libatlas3-base

  • libopenmpi-dev

  • openmpi-bin

  • libssl-dev

  • build-essential

  • libncurses5

  • libncurses5-dev

  • zip

  • uuid-dev

  • libfreetype6-dev

  • tk-dev

  • libhdf5-dev

  • libsqlite3-dev

  • gfortran

You can accomplish this by executing:

$ sudo apt-get install libbz2-dev libatlas-base-dev libatlas3-base libopenmpi-dev openmpi-bin libssl-dev build-essential libncurses5 libncurses5-dev zip uuid-dev libfreetype6-dev tk-dev libhdf5-dev mercurial libsqlite3-dev gfortran

Slow simulation NS2D over a biperiodic space?

Original report (archived issue) by Pierre Augier (Bitbucket: paugier).

The original report had attachments: ns2d_rot.py, dedalus.cfg


Hi,

I am Pierre Augier, one of the developer of fluidsim (https://bitbucket.org/fluiddyn/fluidsim).

In order to compare our performance with other pseudo-spectral CFD codes, we tried Dedalus.

I suspect that we are not doing it the right way (see our script https://bitbucket.org/fluiddyn/fluidsim/src/master/bench/dedalus/ns2d_rot.py) because Dedalus is much (approximately 30 times on my computer) slower than the other codes.

Since we are going to include these comparisons in an article, we would like to get the best of Dedalus. Is there something that I can do to get better performance with Dedalus for this very simple case (NS2D over a biperiodic space, 10 time steps)?

I tried with 512**2 and 1024**2 and I got similar results.

Non-constant coefficients

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


Add Chebyshev expansions of the A, B matrices in order to deal with non-constant coefficients in the linear parts of the equations.

The initial structure may involve hand-coding matrices for a few modes, but this should quickly be replaced by an automatic expansion into P-many modes after the user specifies the coefficients as a function, i.e. "rho_0(z)". This might be done using simple Python lambda functions, but we should also think of using sympy for this.

Properly handle singleton dimensions

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


We should think about better handling of singleton dimensions, to e.g. allow NLBVPs on "multidimensional" domains where the Fourier directions are size=1 (constant). This would make it easier to turn a 3D script into a 2D/1D script, and probably easier to combine problems by solving for a 1d background function and using it in a higher-dimensional simulation.

Stable Releases

Original report (archived issue) by Evan Anders (Bitbucket: evanhanders).


It's that time of year again when Ben's math methods class is tasked with installing Dedalus...and it seems like they're having only slightly less trouble than we had a year ago. A Mac seems to have successfully installed Dedalus with ease, whereas last year the students with Macs essentially gave up. And now (see user group thread by Adam Schiff) Ubuntu seems to be the OS with weird problems.

Would it be possible to prepare "stable releases" of Dedalus? Basically rather than having anyone new to Dedalus install the cutting-edge newest pushes from the repository, it might be better to have installation options that look at older, more stable commits.

The easiest way to implement this would probably be to add a line to the install script that points to the commit that it should be updated to (rather than tip).

This isn't at all crucial, but someone mentioned it begrudgingly today (something along the lines of "grumble grumble introduce the idea of stable releases") and I figured I'd pass it along.

Proper evaluation of duplicated subtrees

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


I've come across an interesting parser/substitution problem with the integ() operator, when applied across the whole domain. This is for a 2-D problem, Fourier ("x") -- Chebyshev ("z").

I defined two averaging types, one over planes perpendicular to the chebyshev direction, and one over the whole domain:

#!python

problem.substitutions['plane_avg(A)'] = 'integ(A, "x")/Lx'
problem.substitutions['vol_avg(A)']   = 'integ(A)/Lx/Lz'

and a substitiution:

#!python


problem.substitutions['enstrophy'] = '(dx(w) - u_z)**2'

After setting up equations, etc. I initialize slice, profile_avg and vol_avg (scalar) outputs, each in their own file:

#!python

analysis_slice = solver.evaluator.add_file_handler(data_dir+"slices", max_writes=20, parallel=False, **kwargs)
analysis_slice.add_task("enstrophy", name="enstrophy")

analysis_profile = solver.evaluator.add_file_handler(data_dir+"profiles", max_writes=20, parallel=False, **kwargs)
analysis_profile.add_task("plane_avg(enstrophy)", name="enstrophy")

analysis_scalar = solver.evaluator.add_file_handler(data_dir+"scalar", max_writes=20, parallel=False, **kwargs)
analysis_scalar.add_task("vol_avg(enstrophy)", name="enstrophy")

That code fails with the following grid-data error:

#!python


Traceback (most recent call last):
File "FC_fixed_kappa_1e6.py", line 111, in <module>
solver.step(dt)
File "/u/bpbrown/build/dedalus/dedalus/core/solvers.py", line 339, in step
self.timestepper.step(self, dt, wall_time)
File "/u/bpbrown/build/dedalus/dedalus/core/timesteppers.py", line 528, in step
evaluator.evaluate_scheduled(wall_time, solver.sim_time, iteration)
File "/u/bpbrown/build/dedalus/dedalus/core/evaluator.py", line 97, in evaluate_scheduled
self.evaluate_handlers(scheduled_handlers, wall_time, sim_time, iteration)
File "/u/bpbrown/build/dedalus/dedalus/core/evaluator.py", line 127, in evaluate_handlers
self.domain.dist.paths[next_index].decrement(fields)
File "/u/bpbrown/build/dedalus/dedalus/core/distributor.py", line 343, in decrement
self.decrement_single(field)
File "/u/bpbrown/build/dedalus/dedalus/core/distributor.py", line 323, in decrement_single
self.basis.forward(gdata, cdata, self.axis, field.meta[self.axis])
File "/u/bpbrown/build/dedalus/dedalus/core/basis.py", line 717, in _forward_fftw
cdata, gdata = self.check_arrays(cdata, gdata, axis)
File "/u/bpbrown/build/dedalus/dedalus/core/basis.py", line 148, in check_arrays
raise ValueError("gdata does not match grid_dtype")
ValueError: gdata does not match grid_dtype

Changing only the very last line of the analysis code block:

#!python

analysis_scalar.add_task("vol_avg(enstrophy)", name="enstrophy")

to do the substitution manually:

#!python

analysis_scalar.add_task("vol_avg((dx(w) - u_z)**2)", name="enstrophy")

causes the code to run fine and trigger no such error.

This seems like some form of substitution/parser bug. Any ideas?

Moveable auto installation

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


It might be nice if the isolated build coming out of the install script could be moved around the filesystem. I'm not sure how feasible this is, but it would just be convenient if you decide you want to move/rename your installation and don't want to take the time to rebuild it all.

I'm not sure if this would just require changes to the activate script or if the linking during the build would also need to be changed?

Non-linear products

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


Add framework for (at least) quadratic non-linearities.

This may involve a task list that directs differentiation and transforms to most efficiently (in memory, by not bringing along unneeded fields, and in speed, by not repeating any computations) construct the non-linear terms.

It should also incorporate the RHS of the boundary condition equations, eliminating the current "pencil.b" structure.

Add integrate method to basis

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


The basis class should have an integrate method, like the differentiate method, to take advantage of basis-specific integration techniques. This will be useful on data output, if nowhere else.

Preallocate output option messed up NCCs?

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


When running the Lane-Emden example NLBVP with the config option PREALLOCATE_OUTPUTS turned on, the solver converges algebraically rather than geometrically, probably indicating that something is going awry with recomputing the LHS NCCs.

Allow non-simulation processes to handle e.g. IO

Original report (archived issue) by Geoffrey Vasil (Bitbucket: gvasil).


Joe Werne (who really knows a lot about what he's doing) does something equivalent to the following with IO:

We're going to want the data in different formats, orderings, FFT spaces, reductions etc.

When it's an IO time step, it's a good idea to have the compute cores dump out their data in the format they happen to have it in at the time. After that, a smaller number of dedicated analysis cores clean up and package the data into the format requested by the user.

I.e., Given the user's requested data product, the analysis cores ask for raw data from the compute cores at a point in the compute loop that corresponds closest to the needed type. The compute cores dump out as fast as possible, and move on. If we want the compute cores to limit the overall efficiency, then the number of analysis cores will scale in some proportion to the frequency of output, and complexity of reduction.

At worst, the compute cores create a backlog for the analysis cores. In this case, at the end of a simulation, the compute cores can switch to analysis and help clear the backlog.

xrange() deprecated in python3, switch to range()?

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


The xrange() function appears to be deprecated in python3. Running liveplot.py in dedalus2/test with python3 throws a `xrange() undefined

It appears in the python2 documentation

http://docs.python.org/3/library/functions.html

but is missing in the python3 docs:

http://docs.python.org/3/library/functions.html

affects:
dedalus2/test/liveplot.py

note:
dedalus2/test/cgle/liveplot.py is fine and already had done xrange() -> range(), so you're probably already aware of this.

Simulations with uncoupled matrices fail

Original report (archived issue) by J. S. Oishi (Bitbucket: jsoishi).


Simulations without coupled bases (e.g. Fourier and Sin/Cos) now fail when the timestepper checks the Pencil.dirichlet attribute. This is because the dirichlet attribute is only added for coupled matrices.

Non-integer resolution values don't work with Fourier bases

Original report (archived issue) by Jhett Bordwell (Bitbucket: jhbordwell).


When providing a non-integer value for the number of elements when initializing a Fourier basis, Dedalus spits out the error that,

Traceback (most recent call last):

File "nd_dust_model_2d.py", line 28, in

domain = de.Domain([x_basis, y_basis], grid_dtype=np.float64)

File "/usr/local/dedalus/src/dedalus/dedalus/core/domain.py", line 46, in init
grid_dtype = basis.set_dtype(grid_dtype)

File "/usr/local/dedalus/src/dedalus/dedalus/core/basis.py", line 609, in set_dtype
native_wavenumbers = np.roll(np.arange(-kmax, kmax+1), -kmax)

File "/usr/local/dedalus/lib/python3.4/site-packages/numpy/core/numeric.py", line 1294, in roll
res = a.take(indexes, axis)

TypeError: Cannot cast array data from dtype('float64') to dtype('int64') according to the rule 'safe'

Switch to Python 3

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


This may be a good time to switch over to Python 3, since we're in the middle of a large rewrite and the current codebase is still pretty small.

I've done some tests and the current code can run under Python 3 with just a few small syntax modifications. All current dependencies support Python 3.

Sympy, mpi4py, h5py, and cython all support Python 3, as well. Any other potential dependencies to check?

Liveplot animation vs frames

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).


This is a forward-looking bug notice.

When grabbing Keaton's branch and testing one of the 2d problems, I noticed that the liveplot routines weren't posting anything to the screen. The problem likely stems from incompatibilities between how matplotlib does animations and what mac os allows. This is a known and currently unresolvable issue (e.g., matplotlib/matplotlib#531) having to do with the macosx backend.

One short term solution is to output individual frames, and then stitch them together after the fact. To do this in the various liveplot.py, replace

fig.canvas.draw()

with

fig.savefig("frame_"+str("{0:04}").format(i)+".png", dpi=200)

or similar.

Here's a possible longer term workaround:
http://nbviewer.ipython.org/urls/raw.github.com/jakevdp/matplotlib_pydata2013/master/notebooks/05_Animations.ipynb

Haven't tested it yet, as I don't know how to open Ipython notebooks yet.

Time-step stability tests (advection-diffusion first)

Original report (archived issue) by Benjamin Brown (Bitbucket: Benjamin Brown).

The original report had attachments: 1d_burgers_equation_chebyshev.png


Dedalus needs a time-step stability test suite.

We need an automated testing suite that can map out the stability domain for our different time-stepping algorithms. In particular, we should be able to create stability region maps like in Ascher et al. 1995 and Canuto et al. Appendix D, Figures D1 & D2.

In Dedalus, we can do this by solving a given linear equation set on a grid of variables, testing whether the amplitude (maybe integrated over the domain; L2 norm?) grows between successive timesteps.

Most previous work has been done semi-analytically and only addresses 2nd order finite difference or fourier spectra. An advantage over work done previously is that we can numerically map out this stability domain for chebyshev and legendre grids, where some of the answers are not well known and hueristic rules are generally applied.

We can also map this domain out for different equation sets. We should start with the simple 1-D advection-diffusion test, with

       \partial_t Y = - c \partial_x Y + \lambda \partial_{xx} Y

and constant advection speed c and diffusion coefficient lambda, but we could eventually test the thermal mode equation, etc.

This is straightforward to do for linear equation sets. Testing non-linear timestepping is more challenging, but we might look at Burgers equation (as in Ascher et al. 1995).

I can't assign this to me right now, but I'll take this on, as I need to understand why the CNAB3 timestepper is going unstable for an entropy-diffusion test.

--Ben

Replace use of absolute() with resolve() in FileHandler

Original report (archived issue) by Jacob Wenegrat (Bitbucket: wenegrat).


On line 329 of evaluator.py the supplied base_path is converted to an absolute path using:
base_path = pathlib.Path(base_path).absolute()

Note however that absolute() may not be very well tested: https://bugs.python.org/issue29688, and regardless does not do as complete a normalization as might be required: https://github.com/python/cpython/blob/355f16fd4beb36d6a18f7d0982581c93de015c17/Lib/pathlib.py#L1118

Instead a better option is pathlib.Path.resolve()
https://github.com/python/cpython/blob/355f16fd4beb36d6a18f7d0982581c93de015c17/Lib/pathlib.py#L1136

This change is motivated by problems I have had running across multiple cores on beegfs filesystems (as documented here: https://groups.google.com/forum/#!topic/dedalus-users/Bj4Ax7bFUcI). Switching absolute() to resolve() on line 329 of evaluator.py appears to have fixed these filesystem errors for me.

Jacob

Piecewise bases

Original report (archived issue) by Keaton Burns (Bitbucket: kburns).


Create a PiecewiseBasis class that splits a direction into multiple bases. Will need to patch together the individual basis matrices, make sure they are defined on continuous ranges, and enforce continuity between them (using N-1 of the boundary condition rows when patching together N individual bases).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.