Volunteering to fix F@H Viewer

[bruce]

The same guy has to priorities all the bugs, compare with his available time, and pick the most important one(s). The decision to opening up the codebase for FAHViewer is independent of the decision to open the codebase for FAHControl or for FAHCore_xx so you'd start with a subset of the heap.

[str4d]

Hi! I'm not yet completely sure what you're referring to here. What did you go in to fix?
In the last release the viewer only works on demo mode.

That was the bug I was motivated to fix, but as I said in this comment it looks like the bug was fixed last year, after the 7.5.1 release.

The same guy has to priorities all the bugs, compare with his available time, and pick the most important one(s).

Yep, given the development history of the project this makes sense. It's just a case of now triaging the influx of users and their requests, and pointing them in the right direction. Fortunately GitHub has added tooling that improves the UX around this (fah-issues PR, fah-viewer PR).

[Quantize]

Meerteen, if you do that, I'll send you some (detailed/constructive) bug reports!

You're up.

[Quantize]

That was the bug I was motivated to fix, but as I said in this comment it looks like the bug was fixed last year, after the 7.5.1 release.

Looking at that comment: It's funny how things can be left unfixed for years and years, everyone complaining and begging, zero dev activity whatsoever.
And then when someone finally steps up to the plate, other devs suddenly also rush to be the first to get it. Or so it looks from my end.

The same guy has to priorities all the bugs, compare with his available time, and pick the most important one(s).

Yes that makes total sense but it doesn't seem to fully answer the question:
What's the deal with having 1 tab open instead of 3? How exactly does that make it easier to work for you/him?

I'd genuinely like to know because I'm new to working with Github.

[Jorgeminator]

There was a workaround mentioned recently: by using the previous viewer executable (and a required dll) file with the current FAH v7.5.1 installation for viewing Core_22 on Windows

True, but the data it's showing is incorrect. @Quantize, you may want to correct me if I'm wrong, but Core_22 seems to be putting broken data into the json files which the viewer uses for its trajectory calculations. My best bet is that the cloud of purple atoms forming a cube consist of these "unknown" atoms with a question mark. Below is a comparison of the working Gromacs A7 data and the broken Core_22 data.

Gro_A7 viewerTop.json:

Code: Select all

"units": "ANGSTROM", "atoms": [
["N", 0.0017, 0.155, 14.01, 7, "GLU"],
["H1", 0.2391, 0.13, 1.008, 1, "GLU"],
["H2", 0.2391, 0.13, 1.008, 1, "GLU"],
["H3", 0.2391, 0.13, 1.008, 1, "GLU"],
["CA", 0.0588, 0.17, 12.01, 6, "GLU"],
["HA", 0.1202, 0.12, 1.008, 1, "GLU"],
["CB", 0.0909, 0.17, 12.01, 6, "GLU"],
["HB1", -0.0232, 0.12, 1.008, 1, "GLU"],
["HB2", -0.0232, 0.12, 1.008, 1, "GLU"],
["CG", -0.0236, 0.17, 12.01, 6, "GLU"],
["HG1", -0.0315, 0.12, 1.008, 1, "GLU"]

Core_22 viewerTop.json:

Code: Select all

"units": "A","atoms": [
["?",0,0,0,3],
["C",0,0,0,6],
["O",0,0,0,8],
["?",0,0,0,4],
["?",0,0,0,4],
["?",0,0,0,4],
["?",0,0,0,11],
["?",0,0,0,9],
["C",0,0,0,6],
["O",0,0,0,8],
["?",0,0,0,6],
["S",0,0,0,16]

[dfgirl12]

My guess without looking into it much: I think the layout of the atoms is correct, but the colors and the sizes of the purple atoms is not correct (probably due to the format and ?'s in the json above).
I'm pretty sure the cube of atoms is a lot of water molecules (like the protein is moving in moisture/water, like in your lungs).
So those should be like a medium sized red atom with a pair of smaller light gray atoms, instead of purple and all the same size.

[Jorgeminator]

My guess without looking into it much: I think the layout of the atoms is correct, but the colors and the sizes of the purple atoms is not correct (probably due to the '?' in the json).
I'm pretty sure the cube of atoms is a lot of water molecules (like the protein is moving in moisture/water, like in your lungs).
So those should be like a medium sized red atom with a pair of smaller light gray atoms, instead of purple and all the same size.

I think you are right. Bruce also said in another thread that they are water surrounding the protein. Now that I looked closer, they are in groups of three atoms, most likely H2O just like you said. They should not be visible at all.
I forked the repo and made a quick and dirty change to the code to make the purple particles fully transparent, but I'm unable to set up a compiling environment. If someone would like to try compiling it the repo is here: https://github.com/Jorgeminator/fah-viewer.
The protein will be missing its hydrogen atoms, but it should at least look a lot better than before, while we wait for a proper fix.

PS.
Looking at the project data on Github, I'm now certain that the purple "cube" surrounding the protein consists of water molecules. https://raw.githubusercontent.com/Foldi ... lvated.pdb
Additionally, the protein contains hydrogen (light gray) and nitrogen (blue) atoms. For some reason these atoms don't get sent correctly by the core and turn up purple.

[Quantize]

I forked the repo and made a quick and dirty change to the code to make the purple particles fully transparent, but I'm unable to set up a compiling environment. If someone would like to try compiling it the repo is here: https://github.com/Jorgeminator/fah-viewer.
The protein will be missing its hydrogen atoms, but it should at least look a lot better than before, while we wait for a proper fix.

I compiled your fork and unfortunately by no means did it resolve the issue.
Still shows pretty much the same cube, then suddenly switches slot, and finally goes for a crash-landing to desktop.

I've recently been working on a fork myself where the 0x22 is excepted, for now.
All non-0x22 cores will be perfectly simulated, viewer is stable, and also some other improvements.

This should give us some ease of mind knowing that the viewer has been Live for COVID-19 while we're still working out 0x22.

[Jorgeminator]

Thank you for testing. The crash to desktop seems to happen with multiple slots active. The viewer never crashes when I fold GPU only (one slot).

[i420bdawg]

@Quantize, if you want a tester I am available. i would really like to have the visualization up when i'm folding@home. i tried other workarounds but i get almost the entire area filled with purple objects. Please, DM me if you want more details.

[Quantize]

Just now I have committed a pull request on GitHub:
https://github.com/FoldingAtHome/fah-viewer/pull/19

Everyone who wants to test please do so now:
http://meertronix.com/FAHViewer.exe

[Neklor]

Thanks, this works with the CPU slot.
When I switch to the GPU slot the viewer freezes and I have to restart it.

[Jorgeminator]

Just now I have committed a pull request on GitHub:
https://github.com/FoldingAtHome/fah-viewer/pull/19

Everyone who wants to test please do so now:
http://meertronix.com/FAHViewer.exe

Most times the viewer tries to open the GPU slot and I have to restart it to view the CPU project. Trying to switch slots inside the viewer works now and then.

[rixon]

Meerteen, if you do that, I'll send you some (detailed/constructive) bug reports!

You're up.

Re-reading this thread, I misread that you were talking about the viewer. I had bug reports for the client. That said, great work with this so far! I'll give it a try some day when I have access to a Windows system.

[Quantize]

Most times the viewer tries to open the GPU slot and I have to restart it to view the CPU project. Trying to switch slots inside the viewer works now and then.

Most people don't know how to change slots. So what's relevant for this promo is: have you waited long enough?
The viewer needs some time, up to 30 seconds, to automatically find the CPU slot. It switches by itself.