Kyle Conroy

Any ideas what might be going on or how best to debug this @horvatm? I also just realized that you can probably get around this in the meantime by requesting...

@dirkterrell - that is definitely odd that `get_passband` works but `run_compute` is raising the error. One other possibility is that it is actually the bolometric passband (used for irradiation), not...

No, its not that modular. But if you look at phoebe.backend.potentials.discretize_wd_style in the master branch, it should be quite straightforward to replicate the logic in the legacy wrapper.

Not just plotting, but also to inspect the mesh and compare with our WD-mesh implementation directly. I think it's the wrapper's job to translate everything to match the format provided...

For 2.0 - let's just make sure that no incorrect meshes are exposed to the user. We can deal with empty meshes for now. Once that is confirmed, go ahead...

Just an update after 2.1 - meshes are now/still ordered correctly to compare to internal WD-style meshing but the uvw coordinates (on plane-of-sky) are still not exposed (and return an...

Hi Ayush - when you call [phoebe.mpi_on](http://phoebe-project.org/docs/2.3/api/phoebe.mpi_on) within a single thread, it handles that by exporting run_compute/run_solver within mpirun in a separate thread. Because of this, I'm not sure it...

To help reproduce this: * what version of phoebe are you running (`print(phoebe.__version__)`)? * what is the output of `print(phoebe.get_passband('Johnson:V').timestamp)`? * did you make any modifications from the [sun example...

This seems to be compiler dependent and you might even find that it happens somewhat randomly. @aprsa has (independently of this report) reproduced the same problem and we are working...

I currently listed this under 2.0 - is this something we need to discuss and include for 2.0b or can we postpone it?