__mp

I take a major issue in their usage of OpenWRT. It seems to me that every hardware I touch with OpenWRT included is out of date - or "well aged". As soon as you try to modify something in the OpenWrt interface and/or update the system, half of the features do not work anymore - luckily the reset button usually works. At least the OpenWRT variant they are choosing looks recent. Good luck!

I'm at the point where I only get Raspberry PI-based hardware. This way I know that I'm able to update/or reinstall in a year or two.

We run the Atlassian products Jira, Confluence and Crucible and soon Bitbucket on premise. Gitlab is not an option because our main repository is a relatively big Mercurial repository. There's also a couple of Jenkins servers.

Most of the on premise IT, with the exception of the Jenkins servers, are managed by a local devops company.

We are a small company with 7 employees.

Social events, the occasional book/movie, tech-related stuff, photography and sports: Hiking and mountainbiking in summer, and splitboarding in winter.

Could be interesting for continuous integration and testing new Cray setups.

I usually have to spend a week or so to adapt our builds once we get a system upgrade. It's mostly to hack around weird Cray setups and because we dare to link C++ and Fortran code bases on GPU.

Here’s a 360 degree video of the gotthard base tunnel: https://youtu.be/i0kdT5oEN2Q In contrast to the Seattle project there are two tunnels running side by side. More information: https://en.m.wikipedia.org/wiki/Gotthard_Base_Tunnel

I can totally see myself in this place 20-ish years ago.

Actually I am in this position. I rather visit the people and enjoy a weekend with them than put on a VR headset. Also it's a great excuse to go away for a weekend. And if it has to be something interactive I found video conferences quite practical. Also if a meeting is important I prefer to be present than remote because it is easier to gauge reactions of people.

I can definitely see some usecases of these experiences. Not wanting to sound too negative, I would prefer to meet the people in person and drink a beer, eat a meal than to lounge around in some virtual room. I see the allure of it if you are staying in a place that is hard to reach. But travel itself is also an experience that can be enjoyed - even more so if it is far away and exotic.

Jettison looks like a nice app.

I'm wondering how they will stack up against XeonPhi.

I think this would be too expensive for us. Why do they take so long? What area are you working in? Would it make sense to scale down the tests to a sensible size and do the longer tests over the weekends?

I think this really depends on the code base. If I had a website where a change would trigger more than 5 minutes of integrating and testing I would go mad.

I'm working with a weather model and it takes around 1 hour to build and test everything: We build against 2 super computers, 3 different compilers, 2 different architectures (CPU, GPU) and single and double precision. Building alone takes 30 minutes (more in some cases). For testing we reserve 1x node with 8 GPUs and 9 CPU cores on one machine and 2x nodes with 1 GPUs in a 30 minutes debug slot.

With a pull-request based workflow we are able to push to the master multiple times a day. 40 minutes might be achievable by massively revamping our build mechanism and getting jenkins to store gigabytes in build artifacts for each run. However, I do not think it is worth it, because changes can take multiple days, or in some rare cases months to implement. If people need to wait for an hour for their tests to validate that's not so bad.

Haha, yes exactly I meant him. The world is small :)

Oh that's pretty neat. A colleague of mine is working on a similar project applying directives to allow loop reorderings for OpenACC and OpenMP code (CLAW project). He's using the Omni-Compiler tough.

Cool, then you are probably the a person who is able to answer this question: What is a good way to mix C++ and Fortran build environments? Is there a way to mix the PrgEnv-{Cray/PGI} so that I can compile C++/CUDA code with GCC 5.x/6.x and the Fortran code in OpenACC mode with PGI/Cray?

Right now, we have quite a elaborate build environment where we first load the GCC build environment to compile the C++ code base. Then we load a Fortran build environment to compile the Fortran code base. I would rather have to use one environment to work in. In the most recent Cray and PGI environments (6.0.3) I have to also add the linker path to GCC version I used for C++. This is to avoid linker issues with the C++11 abi in the newer GCC compilers (somehow, the Cray/PGI environment always wants to link with old GCC libraries). Its not a big problem with our build scripts but annoying nevertheless.

You're welcome. This is what they presented last year: ftp://ftp-anon.dwd.de/pub/DWD/Forschung_und_Entwicklung/CUS2016_presentations_PDF/06_Dynamics_and_Numerics/01_Invited_Z%E4ngl/ICON_CUS_2016.pdf very nice stuff! (there's a seminar at DWD next week where they probably will give an update). The ICON model is also interesting because they are able to interleave a local area model over Europe with their global model.

Well, actually it's actually mostly Jenkins that runs the code for us on Daint. ETH, which I'm also affiliated with, is starting to use the model in GPU mode for climate runs on Daint.

What are you working on at Cray?

Yes, exactly: Piz Kesch and Escha. The code is currently also run on Piz Daint on Pascal. Piz Kesch/Escha is pretty special because the system has 16 GPUs per node which makes the MPI configuration pretty hairy compared to one GPU systems like daint.

I meant it as a general trend. There's interest from the community to run the GPU model on their system but unfortunately the official COSMO code is not fully GPU ready yet.

Yes

A reason for the slow adoption of accelerators is that these code bases are pretty old and mostly Fortran based. I don't think we are going to see a shift to accelerator-based weather models any time soon. The code bases are pretty old and most scientists working on these models don't have the experience or do not want to work in a programming methodology that works well with accelerators (at least that's my experience). Also in a lot of cases people just like to work with an already existing code because they are just doing a PhD and don't want to translate everything to a new language.

The COSMO model which I'm working on is 18 years old. We ported the compute intensive part of the model to C++ using a stencil library and integrated OpenACC pragmas (think OpenMP, but for GPUs) in the rest of the code base.

I'm not a big fan of OpenACC, because it requires the user to make assumptions on the underlying hardware and quite a bit of thinking to get high-performance code. It is quite time consuming to integrate the pragmas so that the code performs. OpenACC capable compilers used to be very unstable, we regularly got compiler breakages and regressions. It got a bit better since we send the code to the vendors, but we still see regressions from time to time. All (usable) OpenACC implementations are proprietary, so we have a vendor dependency. The PGI OpenACC binaries used to be pretty slow, but it is now almost up to par with the Cray binaries.

The successor model to COSMO, ICON, developed at DWD and MPI is also written in Fortran using OpenACC pragmas (and I think OpenMP pragmas because they plan to use it on XeonPhi). The code is interesting in the sense that they are using a icosahedral grid, which stands in contrast to the square grid COSMO uses: Data accesses are not straightforward. Keep in mind that Fortran does not have easy abstractions for data accesses outside of square grids, so you have to use a couple of macros/functions/etc.. to get to the fields you need. Disclaimer: I have not seen the code myself, but the DWD certainly knows how to write high-performance code, so I'm certain most of the code is optimized.

Cool, I think rust needs some time to mature.

I'm currently looking for a rust guide that shows me some programming patterns.

For example:

- How to best implement an observer pattern

- Best practices for vector code

- Best practices for tree implementations and how to implement a lambda on top of it.

I'm interested in small snippets so that I can get some initial productive code and progress from there.

I think the most powerful feature of C++ is templating. Templating makes it very easy to write high-performance math code (no dynamic function calls, everything unrolled by the compiler...).

Just have a look at the state of the art math libraries in rust and compare it to something like Eigen or Cgal. The C++ code is way more flexible and expressive than the rust code. If you don't believe me, check how the rust libraries handle matrix implementations. Often you will find specialized implementations of 1x1 to 4x4 matrices but no generic n-dimensional matrix code.

I've been recently driving in Australia and the behavior is spot on. Cars were overtaking on the left (inner sode of the road) as well.

I have the same problem. I don't even see an option to change a spec all I get is the 256GB/8GB/i5 base model in all the configurations. It's also not possible to change the keyboard layout for my region (CH/DE).

http://i.imgur.com/CqYtvyH.png

I am using https://bazqux.com (paid). It is crazy fast (it is written in Haskell), has a very bare interface and it supports Fever for mobile app integration.

Edit: There's also support for youtube channels: http://blog.bazqux.com/2015/06/subscribing-to-youtube-feeds....

It's a simple finite differences discretization on a rectangular grid. The computations are horizontally explicit and vertically implicit (data dependencies in the vertical direction).

Here's the scientific description of the model: http://www2.cosmo-model.org/content/model/documentation/core...

MeteoSwiss uses a 12 node cluster with 16 GPUs each to compute its weather forecasts (Piz Escha/Kesch). The machine is in operation since more than a year. We were able to disable the old machine (Piz Albis/Lema) last week.

The 1.1km forecast runs on 144 GPUs, the 2.2km probabilistic ensemble forecast is computed on 168 GPUs (8 GPUs or 1/2 node per ensemble member). The 7km EU forecast is run on 8 GPUs as well.

I can't elaborate about it. Sorry.

Disney Research Zürich is super awesome. I did my master thesis there

I can't downvote. How much Karma do I need to activate it?

Thanks :). I must have been somewhere else.