Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upMove to 64bit APSIM Next Generation #2199
Comments
|
Hmmm. 64-bit SQLite shouldn't be a problem, but 64-bit Gtk# may be a bit harder. Of course we're already running 64-bit on Linux and OS X - the problem is getting a suitable set of native DLLs for 64-bit Windows. |
|
Hi @zur003. We are needing to do some project planning and plans will depend alot on if APSIMX can go 64bit and solve the memory problems we are having. Can you give an estimate on how hard or easy you think this will be and how long you think it may take. |
|
Hi josharp22 |
|
Hi @josharp22 . The problem is the lack of support for 64-bit Gtk# on Windows, so we can't readily run the GUI as 64-bit. This isn't likely to change anytime soon. You have a couple of short-term options: (1) Run the model without the GUI (this will require the 64-bit version of Sqlite, but that's readily available) or (2) work on a Linux or Macintosh system instead of Windows; on those platforms we ought to be able to run everything as 64-bit (though I now realise that I haven't actually tested this). I kind of suspect the only way we're going to get everything running as 64-bit on Windows is to rebuild all the Gtk# support from source code, and that's not a trivial exercise - and even we try, we're likely to find there's some technical difficulty that would account for why this hasn't already been done by the good folks at the Mono project. I suppose another possibility is to run the GUI as 32-bit, and find some magic that would allow us to run the model as 64-bit. I don't really know how feasible this might be. |
|
Thanks @zur003 that's really helpful. I think running a 64-bit version of the model without the GUI is the best option. How do we go about doing that? |
|
Running the model in 64-bit from the command line is fairly easy, provided you're compiling from source code. In Visual Studio, you just need to go to the Properties for the Models project, and on the "Build" tab, clear the check box that says "Prefer 32-bit", and re-compile. You can then run ApsimX models using a command line like: 'Models.exe "Path_to_my_model.apsimx"'. The only other thing is that you will need to do is to have the 64-bit version of sqlite3.dll int the Bin folder, instead of the 32-bit version. If you have the wrong version of the dll, a BadImageFormatException will be thrown. Admittedly, it's kind of a nuisance to have to switch between versions of the sqlite DLL. I should have a chat with @hol353 about whether we can package this up in some tidy way. |
|
@hol353 - After a couple days of tinkering with the Gtk# source code, I've been able to get a fully 64-bit version of the GUI up and running on Windows. This now raises the question of how we should be handling distribution of ApsimX Next Generation on Windows. The .NET assemblies are platform-neutral, but on Wiindows there are a large number (over 30) of supporting native DLLs that must either all be 32-bit or 64-bit. I see several options:
Option 1 is the simplest; options 3 and 4 should be possible, but I'm not sure how difficult they would be to get working properly. Consider also that 32 and 64 bit versions use different floating point mechanisms. (If I understand correctly, with the Windows .Net runtime, 32-bit uses the FPU, but 64-bit uses SSE2 for floating-point calculations. See https://stackoverflow.com/questions/33153445/changes-to-math-exp-or-double-implementation-in-net-4-5-2 for a bit more information, I don't know what Mono does, either on Windows or other platforms.) This means that 32 and 64 bit versions will often give slightly different results. There's also the question of running Apsim Next Generation on clusters or the cloud - can we always guarantee a 64-bit environment? Thinking about it, though, this latter bit probably isn't a serious problem, as cloud runs normally wouldn't be using the GUI. |
|
Given that we don't have too many users yet and that it is a new piece of software and all modern computers are 64bit, I'm inclined to do the easy option (option 1). |
|
Fully 64bit sounds like a good way to go. |
|
Agree!
From: Neville [mailto:notifications@github.com]
Sent: Wednesday, 7 February 2018 1:30 PM
To: APSIMInitiative/ApsimX <ApsimX@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [APSIMInitiative/ApsimX] Move to 64bit APSIM Next Generation (#2199)
Fully 64bit sounds like a good way to go.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<#2199 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ALnLjcA0p5bvpwFMwpTbcshOfVkG0AMqks5tSO6RgaJpZM4QvyNS>.
|
|
I think fully 64 bit will be the best option |
|
I've put the following message on Slack, but just in case you didn't see it there... "Attention (again) all Apsim Next Generation developers. I am in the process of converting the Windows builds to 64-bit (only), including the Gtk# GUI. If you build Apsim yourself, this means you will need a new set of 64-bit Windows support DLLs to replace the exisiting 32-bit ones. When all this is working, and Dean commits it to GitHub, and you pull the new code, you will find a new folder named ApsimX\DeploymentSupport\Windows\Bin64. If you're working on Windows, copy all the files in this folder into your ApsimX\Bin folder, and you should be able to run the new 64-bit GUI." |
We need this urgently so that large simulations with many zones (e.g. #2195) can run. Val will also probably run into this problem when she explores larger urine patch modelling.
The problem is going to be the third party packages we use in particular the GTK and SQLite .dll files.
@zur003 Do you have time to look into this?