Menu
▾
▴
Re: [Anuga-user] Can't build dev on Windows and Okushiri test
|
From: Stephen R. <u86...@ud...> - 2015-09-25 00:46:06
|
Hi Joaquim, I have attached a short ipython notebook which shows you how to load produce an interpolation function which can produce the stage at specified gauge stations, for the okushiri validation test. Run the simulation, so as to produce the sww file, then fire up the ipython notebook (or just python) to get a plot. Cheers Steve On 24/09/15 03:53, Joaquim Luis wrote: > > Hi Steve, > > Thanks for digging that deep into this issue. Things that I've found > meanwhile. > > In another machine I installed the "Gohlke-Binaries". One thing I > don't like so much in this is that it forces me to install GDAL, > otherwise the installing procedure aborts. It should instead just give > a warning an continue. I do have GDAL and netCDF built by myself and I > would rather be able to use those instead. But not a big deal for this > issue, except that ... see below > > With this installation ANUGA works, although one test stops with an > error something like: > > "Permission denied: > `c:\\temptest_exposure_csv_loading_title_check_list.csv" > > which true because that file does not exist. > > Now, why these binaries work and my own build not? I checked with the > DependencyWalker and indeed it smells something. For my binaries it > complains that the MSVCR90.DLL is not found (see attached image). Or, > that is very strange because it leaves in python root dir, not to > mention that I have it also in the systems dir. For the > "Gohlke-Binaries" on the other hand, that dll is found under those > cryptical dirs that MSVC install is. This is certainly a "manifest" > hell. I tried first solution in > http://kb.froglogic.com/display/KB/Article+-+Errors+with+%28third+party%29+Python+modules > > but no good. > All this points to a problem with my build with MSYS2, but why in a > first place is a MSVC dependency ending up in a mingw built binary? > There must be a "manifest" instruction in the build command that makes > it happen. I never really understood well that manifests shit, except > that they bring a lot of pain. That is so much true that MS drop them > from VS2010 onwards. > > Ok, but now I can run the Okushiri test and extend it to 150 sec. One > one first try to do it anuga complains a lot we are asking a run time > that extends beyonds the boundary condition time. That is true, but it > should complain only once and not one for each time step increment, > which make the run unbearably slow. Also it says that it will use > amplitude for t = 0. I think it should use the amplitude for the last > t in input. > > To finish this, sorry, long mail. Right I could run the simulation but > I'm not able to plot it. The plot_results.py aborts with an error at > the end. > > Where are the gauge result stored? I'm not able to read the netCDF > files with my reader (HDFexplorer) that uses to read everything. I > have a vague recall that the netCDF packages for Python used to ship > with very old netCDF libs. Might it be the case still? > > Fortunately Mirone is still able to read the .sww files so I can look > at this at least. But I wanted to look at the time-series. Again, > where are they? Inside the "okushiri_auto_validation.sww"? > > Cheers > > and thanks again for looking into this as well as to read this far. > > Joaquim > >> Hi Joaquim, >> >> I tried the 32 bit version of winpython 2.7 together with a 32 bit >> version of the mingw compiler. >> >> It installed and ran most of the unit tests successfully. (winpython >> doesn't have gdal so about 10-15 errors because of that.) There were >> a couple of other errors which don't show up on linux, which I will >> fix, but they are not that important. >> >> So you should be able to run the okushiri test with the 32 bit >> version of winpython. >> >> I also tried the 64 bit version of winpython 2.7. It produced a lot >> of errors (as expected), but not the error you have reported. But I >> probably didn't use the correct compiler. >> >> Cheers >> Steve >> >> On 23/09/15 10:02, Joaquim Luis wrote: >>> On Wed, 23 Sep 2015 00:34:07 +0100, Stephen Roberts >>> <u86...@ud...> wrote: >>> >>>> Hi Joaquim, >>>> >>>> I haven't tried winpython (anaconda, pythonxy and using the Gohlke >>>> binaries). >>>> >>>> Is it possible that there are some old anuga files? >>> No. It was after a fresh install (and WinPython is a portable >>> version to >>> avoid contaminations) >>> >>> >>>> Is winpython 32 or 64 bit? >>> 64 >>> >>>> Did you compile with mingw? >>> Yes, with https://msys2.github.io/ >>> >>> >>>> You probably need to build via >>>> >>>> python setup.py build --compiler=mingw32 >>> Did it again but same result. >>> >>>> and then do the install. >>>> >>>> python setup.py install >>>> >>>> You can set that up automatically via. Here is a cut and paste from >>>> https://github.com/GeoscienceAustralia/anuga_core/wiki/Install-ANUGA-on-Windows-using-Gohlke-Binaries >>>> >>>> >>>> >>>> We need to force the python installation scripts to use the TDM-GCC >>>> compiler. Add a configuration file named pydistutils.cfg to your home >>>> directory C:\Users\yourName with the contents:: >>>> >>>> [build] >>>> compiler=mingw32 >>>> >>>> (though maybe winpython already does that?) >>>> >>>> Cheers >>>> Steve >>>> >>>> >>>> >>>> On 23/09/15 08:01, Joaquim Luis wrote: >>>>> Hi Stephen, >>>>> >>>>> Thanks for answer, but no, I don't have a PYTHONPATH variable set. >>>>> And yes, "setup.py install" did install things in >>>>> >>>>> C:\programs\WinPython-2.7.10.2_64\python-2.7.10.amd64\Lib\site-packages\anuga >>>>> >>>>> >>>>> >>>>>> Hi Joaquim, >>>>>> >>>>>> I seem to recall that this problem may be to do with the PYTHONPATH >>>>>> variable. >>>>>> >>>>>> The command >>>>>> >>>>>> python setup.py install >>>>>> >>>>>> should install anuga into the standard site-packages directory. (So >>>>>> no need to set PYTHONPATH) >>>>>> >>>>>> Maybe you have PYTHONPATH set to some other directory? I suggest >>>>>> removing that environment variable if it is set. >>>>>> >>>>>> Let me know if that helps. >>>>>> >>>>>> Cheers >>>>>> Steve >>>>>> >>>>>> On 23/09/2015 5:14 AM, Joaquim Luis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> After a somewhat long period I tried to install anuga again on >>>>>>> Windows >>>>>>> and, for the first time I think, couldn't make it. >>>>>>> My current OS/settings is Win8 with WinPython and msys2. Using >>>>>>> the the >>>>>>> developing version, the step >>>>>>> >>>>>>> python setup.py install >>>>>>> >>>>>>> went with no visible problems but >>>>>>> >>>>>>> python runtests.py >>>>>>> >>>>>>> errors immediately with >>>>>>> >>>>>>> ... >>>>>>> from anuga.coordinate_transforms.geo_reference import >>>>>>> Geo_reference >>>>>>> File >>>>>>> "C:\programs\anuga\anuga_core\build\testenv\Lib\site-packages\anuga\coordinate_transforms\__init__.py", >>>>>>> >>>>>>> >>>>>>> line 2, in <module> >>>>>>> from redfearn import * >>>>>>> File >>>>>>> "C:\programs\anuga\anuga_core\build\testenv\Lib\site-packages\anuga\coordinate_transforms\redfearn.py", >>>>>>> >>>>>>> >>>>>>> line 9, in <module> >>>>>>> from anuga.coordinate_transforms.geo_reference import >>>>>>> Geo_reference, >>>>>>> DEFAULT_ZONE >>>>>>> File >>>>>>> "C:\programs\anuga\anuga_core\build\testenv\Lib\site-packages\anuga\coordinate_transforms\geo_reference.py", >>>>>>> >>>>>>> >>>>>>> line 12, in <module> >>>>>>> from anuga.utilities.numerical_tools import ensure_numeric >>>>>>> File >>>>>>> "C:\programs\anuga\anuga_core\build\testenv\Lib\site-packages\anuga\utilities\numerical_tools.py", >>>>>>> >>>>>>> >>>>>>> line 391, in <module> >>>>>>> from .util_ext import gradient, gradient2 >>>>>>> ImportError: DLL load failed: A dynamic link library (DLL) >>>>>>> initialization >>>>>>> routine failed. >>>>>>> >>>>>>> I can't get it where that "DLL load failed" error is coming from. I >>>>>>> checked the util_ext.pyd with the DependencyWalker and no visible >>>>>>> dependency problem is showing up. >>>>>>> >>>>>>> Anyway, my goal with this was to see again what ANUGA gives for the >>>>>>> Okushiri test (...\validation_tests\experimental_data\okushiri) >>>>>>> >>>>>>> Can ask if someone can run this test but extend it to to run for >>>>>>> 150 >>>>>>> seconds? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Joaquim >>>>>>> ------------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Anuga-user mailing list >>>>>>> Anu...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/anuga-user >>> ------------------------------------------------------------------------------ >>> >>> Monitor Your Dynamic Infrastructure at Any Scale With Datadog! >>> Get real-time metrics from all of your servers, apps and tools >>> in one place. >>> SourceForge users - Click here to start your Free Trial of Datadog now! >>> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 >>> _______________________________________________ >>> Anuga-user mailing list >>> Anu...@li... >>> https://lists.sourceforge.net/lists/listinfo/anuga-user -- +--------------------------------------------------------------------+ | Steve Roberts | My Office: (61)(2) 6125 4445 | | Department of Mathematics | Math Office: (61)(2) 6125 2908 | | Mathematical Sciences Institute| Fax: (61)(2) 6125 4984 | | John Dedman Building #27 | mailto:ste...@an... | | Australian National University | http://www.maths.anu.edu.au/~steve| | Canberra ACT 0200 AUSTRALIA | ANU CRICOS # 00120C | +--------------------------------------------------------------------+ |