Volunteering to fix F@H Viewer

Moderators: Site Moderators, FAHC Science Team

bruce
Posts: 20910
Joined: Thu Nov 29, 2007 10:13 pm
Location: So. Cal.

Re: Volunteering to fix F@H Viewer

Post by 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
Posts: 2
Joined: Sun Mar 22, 2020 10:24 am

Re: Volunteering to fix F@H Viewer

Post by str4d »

Quantize wrote: 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.
bruce wrote: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
Posts: 26
Joined: Mon Mar 16, 2020 1:15 pm

Re: Volunteering to fix F@H Viewer

Post by Quantize »

rixon wrote:Meerteen, if you do that, I'll send you some (detailed/constructive) bug reports!
You're up. :-)
Quantize
Posts: 26
Joined: Mon Mar 16, 2020 1:15 pm

Re: Volunteering to fix F@H Viewer

Post by Quantize »

str4d wrote: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. :P
bruce wrote: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
Posts: 49
Joined: Tue Mar 24, 2020 11:24 am
Location: Finland

Re: Volunteering to fix F@H Viewer

Post by Jorgeminator »

dfgirl12 wrote: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]
Image
Image
dfgirl12
Posts: 38
Joined: Fri Aug 21, 2009 8:34 am

Re: Volunteering to fix F@H Viewer

Post by 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.
Last edited by dfgirl12 on Wed Mar 25, 2020 12:50 pm, edited 1 time in total.
Jorgeminator
Posts: 49
Joined: Tue Mar 24, 2020 11:24 am
Location: Finland

Re: Volunteering to fix F@H Viewer

Post by Jorgeminator »

dfgirl12 wrote: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.
Image
Quantize
Posts: 26
Joined: Mon Mar 16, 2020 1:15 pm

Re: Volunteering to fix F@H Viewer

Post by Quantize »

Jorgeminator wrote: 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
Posts: 49
Joined: Tue Mar 24, 2020 11:24 am
Location: Finland

Re: Volunteering to fix F@H Viewer

Post by 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).
Image
i420bdawg
Posts: 1
Joined: Wed Mar 25, 2020 3:18 pm

Re: Volunteering to fix F@H Viewer

Post by 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
Posts: 26
Joined: Mon Mar 16, 2020 1:15 pm

Re: Volunteering to fix F@H Viewer

Post by 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
Posts: 1
Joined: Thu Mar 26, 2020 8:42 am

Re: Volunteering to fix F@H Viewer

Post by 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
Posts: 49
Joined: Tue Mar 24, 2020 11:24 am
Location: Finland

Re: Volunteering to fix F@H Viewer

Post by Jorgeminator »

Quantize wrote: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.
Image
rixon
Posts: 10
Joined: Sun Mar 15, 2020 5:25 am
Hardware configuration: Linux / Xeon / Tesla / HPC
Location: Kansas City

Re: Volunteering to fix F@H Viewer

Post by rixon »

Quantize wrote:
rixon wrote: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
Posts: 26
Joined: Mon Mar 16, 2020 1:15 pm

Re: Volunteering to fix F@H Viewer

Post by Quantize »

Jorgeminator wrote: 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.
Post Reply