Some tests take too long about espressopp HOT 9 OPEN

these things can be moved to examples, as there is no real testing (the test framework with assert is not used at all).
@acfogarty ?

from espressopp.

They are "testing" some functions/interfaces, at least just for whether it runs without crashing. Another option would be to delete the slowest parts of the scripts, all the file I/O. But I agree it's not really worth it and we should just move them to examples, with the long-term goal of someday having unit tests for those functions...

from espressopp.

The other thing we could do is to mark some tests as big, long or nightly and have them off by default and only enable them in some of the travis builds.

On the other hand we could also just reduce the number of steps for pi_water and polymer_melt_tabulated in the tests and copy a longer version in examples.

from espressopp.

I think for pi_water it is even not possible. At least I haven't seen this possibility. There psfwrite takes quite some time

from espressopp.

Ok, regarding psfwrite I notice that it can suffer the same problem as writexyz at the python level, i.e. looping through all the particles. For example, in the case of writexyz this can be made faster already at the python level by using configurations (this is for example what fastwritexyz does and there are orders of magnitude of difference when dumping a lot of particles, see #77 .
The problem here is that mass and q is needed in addition and right now I don't think (actually don't remember ;)) that this info is passed on with the "Configuration" approach used by fastwritexyz.
This only one part and intuition given I've seen this in #77 because don't know how long the second loop in psfwrite takes (the one over the interactions)...

from espressopp.

How about just doing pi_water and polymer_melt_tabulated for just one time step to test the API and putting a more physical version in examples?

from espressopp.

@junghans Looks like pi_water already runs for only one time step.

@fedepad I think that doing anything to speed up psfwrite is not worth the effort. PSF files only contain info that doesn't change during a simulation, so in practice the user would only call psfwrite a maximum of one time per simulation. So in real applications it doesn't matter if psfwrite is a bit slow, it still takes a completely negligeable amount of time compared to the total simulation time.

I actually added a unit test for psfwrite recently, in testsuite/python_tools, and this test is taking only around 0.4 sec (because I deliberately wrote the test for a tiny number of particles).

from espressopp.

@acfogarty: then we have to decrease the system size for pi_water.

from espressopp.

@junghans Yeah, I think that is better, in particular because they are not benchmarking related!

from espressopp.