Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to 64bit APSIM Next Generation #2199

Closed
hol353 opened this issue Nov 29, 2017 · 15 comments
Closed

Move to 64bit APSIM Next Generation #2199

hol353 opened this issue Nov 29, 2017 · 15 comments

Comments

@hol353
Copy link
Contributor

@hol353 hol353 commented Nov 29, 2017

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?

@zur003
Copy link
Contributor

@zur003 zur003 commented Nov 29, 2017

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.

@HamishBrownPFR
Copy link
Contributor

@HamishBrownPFR HamishBrownPFR commented Dec 13, 2017

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.

@josharp22
Copy link
Contributor

@josharp22 josharp22 commented Jan 28, 2018

Hi @zur003 and @hol353
Is there any update on whether this is likely to happen and what the timescale might be please? As indicated we have a large project that needs to run multiple zones and if this isn't likely to happen need to amend the plan asap.
Cheers.

@hol353
Copy link
Contributor Author

@hol353 hol353 commented Jan 28, 2018

Hi josharp22
This is a job for Eric who has been on long service leave. I'm not sure if he is back this week or next. I'm also not sure what else he has on his todo list. We'll have to wait until he responds to this.

@josharp22
Copy link
Contributor

@josharp22 josharp22 commented Jan 28, 2018

Thanks for the update @hol353 will wait until @zur003 returns.
Cheers.

@zur003
Copy link
Contributor

@zur003 zur003 commented Jan 28, 2018

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.

@josharp22
Copy link
Contributor

@josharp22 josharp22 commented Jan 29, 2018

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?

@zur003
Copy link
Contributor

@zur003 zur003 commented Jan 29, 2018

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.

@zur003
Copy link
Contributor

@zur003 zur003 commented Feb 6, 2018

@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:

  1. We distribute an installer for only the 64-bit version, and hope that no-one is still running 32-bit Windows.
  2. We make both 32 and 64 bit installers available, and the user chooses which is appropriate.
  3. We include both the 32 and 64 bit binaries with the installer, and the installer works out which is appropriate for the current platform.
  4. The installer installs both the 32 and 64 bit binaries, and the application adjusts its search path at startup so that it pulls in the appropriate set.

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.

@hol353
Copy link
Contributor Author

@hol353 hol353 commented Feb 7, 2018

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).

@her123
Copy link
Contributor

@her123 her123 commented Feb 7, 2018

Fully 64bit sounds like a good way to go.

@sno036
Copy link
Contributor

@sno036 sno036 commented Feb 7, 2018

@HamishBrownPFR
Copy link
Contributor

@HamishBrownPFR HamishBrownPFR commented Feb 7, 2018

I think fully 64 bit will be the best option

@zur003
Copy link
Contributor

@zur003 zur003 commented Feb 8, 2018

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."

@hol353 hol353 closed this in #2288 Feb 8, 2018
@josharp22
Copy link
Contributor

@josharp22 josharp22 commented Feb 20, 2018

Hi @zur003 and @hol353
Thank you both very much for your input on this. We can now run large multi-zone simulations! Fantastic :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.