Re: estonian translations

[Daniel Damelin]

Hi Kaido,

Yes, Next Gen MW is open source as you will see from the Github repositories I point to below.

There are three codebases that are affected by the introduction of a new language:

• Lab which provides the underlying engine for the simulations and the interactive layout mechanism.
• Lab-grapher which provides graphing functions.
• Lab-interactives-site which is where the interactives are defined. Once the changes to Lab are done any future translations of interactives will happen just within this codebase.

Ideally, a developer would fork each of those code repositories, run the projects on their local machine to make sure they work, commit the changes, and issue a pull request for our review.

To get started you should join the lab-models google group. That is the best place to ask questions while doing the localization.
https://groups.google.com/forum/#!forum/lab-models

STEP 1: Translate strings for Lab-grapher

The simplest one to translate would actually be Lab Grapher. You only need to update one file to add the Estonian translations: https://github.com/concord-consortium/lab-grapher/blob/master/locales/translations.json 

In fact you could just edit it right on the Github site rather than downloading the entire repo. Just make sure the file passes a JSON lint test. I like to use http://jsonlint.com to validate JSON files.

The two letter code for Estonia is ee.

STEP 2: Translate strings for Lab

You can do the same thing for the strings file in Lab, but it would be helpful to check your work here by translating a simple interactive that we use to demo successful translations. The “Oil and Water” interactive is what we typically use for this. (Note, this interactive is included in this codebase for simple testing. The interactives you want to use in your courses will be in the lab-interactives-site codebase).

To be able to test the translation locally before sending the code, do the following:

• Fork and clone the repo.
• Follow the instructions in the ReadMe to get it up and running locally.
• Use the localization instructions here: https://github.com/concord-consortium/lab/blob/master/developer-doc/localization.md 
• Translate the Oil and Water interactive to test your translation.
• Commit your changes and issue a pull request.

STEP 3: Translate interactives in the Lab-interactives-site

• Fork and clone the repo.
• Follow the instructions in the ReadMe to get it up and running locally. I recommend following the Docker instructions there as this will help eliminate any conflicts with dependencies that have different versions.
• Use the localization instructions here: https://github.com/concord-consortium/lab-interactives-site/blob/master/developer-doc/localization.md (Note, the Oil and Water interactive referred to here is not the same one you translated for STEP 2, so you won’t see your translation. If you want to also translate this, which should be easy since it was already done for the other repo, it would be appreciated, but is not necessary.)
• Find an interactive you are interested in and translate it.
• Commit your changes and issue a pull request.
• Repeat the last two steps for each interactive you want to translate.

Note, since the translations in the Lab-interactives-site depend on translation of Lab you can either wait until we get your translation out into a publicly available version of Lab or you can run Lab locally and select “local” as the Lab environment to use when also running your local version of lab-interactives-site.

 

If you have any questions, it will be best to ask them on the lab-models list, where hopefully, others may correct any instructions I gave here.

-Dan

On Jan 23, 2017, at 4:54 PM, Kaido Reivelt <kaido....@gmail.com> wrote:

Hi Dan and thank you for the reply,

Right now we would like to embed the simulations in our web platform. The multi-page/step activities have to wait a while.

Yes, we have technical persons around, please send the instructions.

BTW, Next-Generation Molecular Workbench engine, is it an open-source software platform?

With best regards,

Kaido Reivelt

2017-01-23 16:18 GMT+02:00 Daniel Damelin <ddam...@concord.org>:

Hi Kaido,

It would be great if you would be interested in translating some of our materials. When you mention simulations and activities I assume you mean both the individual simulations and some of the multi-page activities? Are there specific ones you are interested in?

Regarding simulation translation, is there someone on your end that has some technical capability. It won’t require actual programming, but someone who is familiar with Git file version management and has some technical facility would be required to make that possible.

If you have access to someone like that, then I can send more detailed instructions about how to move forward.

Thanks for your interest. 

-Dan Damelin

On Jan 23, 2017, at 7:25 AM, Kaido Reivelt <kaido....@gmail.com> wrote:

Dear All

Estonian Physical Society and Institute of Physics, University of Tartu aknowledges your work on physics simulations and activities in http://mw.concord.org/nextgen/.

Is it possible to become your partner? Our primary interest is to translate your materials for Estonian physics teachers. But there might be other means for cooperation.

With best regards,

Kaido Reivelt

Estonian Physical Society, UT Centre of Physics Education

[Pär Söderhjelm]

Hello,
Sorry if this is double-posted, I tried to ask this question yesterday
but it seemed to never appear on the list.

The feature I'm missing most in the MD2D model is periodic boundary
conditions. I let the students calculate diffusion coefficients etc. and
particles bouncing at the walls really makes things difficult and
artificial.

Does anyone know if it's implemented in a private version somewhere?
Otherwise, what would be the best way of implementing it? I tried
creating a modified version of bounceParticleOffWalls and it works
reasonably well, but I realize I have to implement minimum image
convention in the interactions between particles as well, and probably
modify how the neighbor lists are treated. Would it be better to build
upon some code that is already in the Java version of the 2D model?

Best regards,
Pär

[Daniel Damelin]

Hi Pär,

It would be great if you were interested in implementing periodic boundaries in NextGen MW. Do you already have a fork and new code in a branch on that fork where you are working?

Some answers interspersed below.

-Dan

> Does anyone know if it's implemented in a private version somewhere? \

I am not aware of this being implemented in any private fork or some other codebase within the Concord Consortium.

> Otherwise, what would be the best way of implementing it? I tried creating a modified version of bounceParticleOffWalls and it works reasonably well, but I realize I have to implement minimum image convention in the interactions between particles as well, and probably modify how the neighbor lists are treated.

I believe you are on the right track here. Piotr Janik worked on the neighbor list implementation as part of engine optimization, so he may have some advice on which parts of MD2D need to be modified to achieve this new feature.

> Would it be better to build upon some code that is already in the Java version of the 2D model?

I don’t believe we used neighbor lists in the same way in the Java version of MW. I know there were cutoffs to improve performance. The source code for Classic (Java) MW can be found here: http://mw.concord.org/modeler/download.html (scroll down to the bottom of the page)

[Piotr Janik]

Hi,

it would be a great new feature.

2017-05-10 16:24 GMT+02:00 Daniel Damelin <ddam...@concord.org>:

> Otherwise, what would be the best way of implementing it? I tried creating a modified version of bounceParticleOffWalls and it works reasonably well, but I realize I have to implement minimum image convention in the interactions between particles as well, and probably modify how the neighbor lists are treated.

I believe you are on the right track here. Piotr Janik worked on the neighbor list implementation as part of engine optimization, so he may have some advice on which parts of MD2D need to be modified to achieve this new feature.

bounceParticleOffWalls and bounceObstacleOffWalls is a good start.

Re neighbor lists, I think they should work in the same way. But the biggest challenge is to find and update all the places where we calculate distance between two particles and obstacles. Unfortunately, we don't use one, common function, but we've been assuming that it's simply: sqrt((x1 - x2)^2 + (y1 - y2)^2). When periodic boundaries are used, it should be something like sqrt(min((x1 - x2)^2, width - (x1 - x2)^2) + min((y1 - y2)^2, height - (y1 - y2)^2)) instead.

Finding all those places and providing a common function might be cumbersome, but probably it's not very complicated.

I'd start with: 

https://github.com/concord-consortium/lab/blob/16cdc1f1b2048b7299e53763e5603b7ac53318e0/src/lab/models/md2d/models/engine/md2d.js

https://github.com/concord-consortium/lab/blob/16cdc1f1b2048b7299e53763e5603b7ac53318e0/src/lab/models/md2d/models/engine/neighbor-list.js

and check if potential calculators don't calculate distance themselves (it doesn't seem so in case of LJ):

https://github.com/concord-consortium/lab/tree/16cdc1f1b2048b7299e53763e5603b7ac53318e0/src/lab/models/md2d/models/engine/potentials

Once it's done, I guess the simplest test would be to run simulation for some time and check if total energy is constant (ofc in simple models where it should be, so heat bath off etc.).

Cheers,

Piotr

 

[Pär Söderhjelm]

Hi,

Thanks Piotr for these pointers. So far I have modified bounceParticleOffWalls, getNeighboringCells, and calculateLJInteraction, and I think it works as it should, for atomistic systems. I also implemented a non-elegant way to get out the "true" coordinates (not limited to the box) so one can compute e.g. mean displacement. Here are a few examples:

http://klur.se/mw/embeddable.html#mixture/mix.json

http://klur.se/mw/embeddable.html#diffusion/diff.json

The neighbor list is a mystery to me, but it seems to work without changes.

I would say that obstacles and shapes are incompatible with periodic boundary conditions for fundamental reasons, at least I will not try to implement it. Systems with charges would require Ewald summation, which unfortunately I don't think I'm capable of implementing. Molecules would be nice, but I think that might be much more difficult than atoms.

So, my question is, would this very limited functionality (neutral atoms in rectangular boxes without obstacles) be of interest to anyone else, so that I should try to contribute these changes?

Best regards,

Pär

--
You received this message because you are subscribed to the Google Groups "lab-models" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lab-models+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Piotr Janik]

Hi,

sorry for the delay! I've missed this email.

It's really nice start. However, I think we would need a complete functionality to be able to merge it into master. 

Here's source code of the Java version: https://github.com/concord-consortium/mw which could be useful too. But I know it's a big feature.

Could you open a pull request to Lab anyway? We won't be able to merge it now, but we'll have this work available in a separate branch. It might be useful in the future.

Thanks!

Piotr

To unsubscribe from this group and stop receiving emails from it, send an email to lab-models+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "lab-models" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lab-models+unsubscribe@googlegroups.com.