A Few Facts

Started by auntdeen

auntdeen Lv 1

From the perspective of someone who has been relatively successful in scoring in NC, and who has done her share of both complaining and problem solving (nailing down bugs)…

We have some facts here that all of us can agree on, whatever our perspectives.

First - we are all finding it difficult to re-establish our rhythm.. by this I mean from hand fold to finished (cemented) protein.

I had been relatively successful with the following pattern - hand work & tweaks in .2 CI, maybe an overall rebuilder script - at .4 CI some mild banding - 1.0 CI more rebuild, banding, drw and whatever else.

I still feel that the method has value, but point by point… handfolding has been difficult because of rebuild (better now)… rebuild scripts were difficult, also better now… banding scripts - what you use to band the protein are still problematic. We know for a fact that wiggle is still inefficient or not quite right, because walking works again - sometimes surprisingly well.

But the hardest thing is that the client keeps changing, and there are almost too many options / choices now - 4 flavors of wiggle added to the option of which CI to use - that is a fact. The devs may be tweaking the scoring functions behind the scenes, because almost every puzzle, even of the same types, reacts differently from each other.

And because of the crashes and hangs, and that many are only able to run fewer clients because of over heating, it's difficult for most folders to fully explore these options to begin to get back into a method that works for them.

The filters have caused overheating issues since they were introduced, and that has continued/gotten worse in NC - but overheating is not limited to mutate puzzles.

Another fact is that we still have a lot of bugs.

The jury is still out on whether the latest devprev update has accomplished anything, for two reasons - many can't devote the clients to test as they used to, and puzzle 854 was released at the same time. Wiggle on that puzzle is horribly buggy, but that's what many used to test the devprev release.

How we approach these issues, and these facts, is how we personally react to frustration. Some of us don't handle it well, some are always optimistic. The full range of reaction is valid - it all stems from the same frustration with the facts.

And our opinions of whether or not these facts can be resolved in time for casp is valid opinion, wherever you fall on the scale. The fact is, because of the above issues, many have cut down the number of clients they run - and the number of puzzles they can devote time to. There is varied opinion on whether the NC will be better for scientific accuracy - or cause the better solutions to go unexplored because of less players running fewer clients.

And a sad fact here - there are fewer players logged into chat - the numbers have declined to 64 in vet at this writing from a relatively consistent over 100 before NC. Global is down dramatically, also.

Every player applauds the devs for trying to bring better accuracy to the game. But another fact is that every last player would like to see that accuracy integrated into a solid, playable and enjoyable game that is stable, and does not cause computers to overheat. The last fact is that we simply don't have that game right now.

wisky Lv 1

Wow. I really could not have put this better myself. Thank you for your frank comments on this (contentious) issue.

alcor29 Lv 1

I agree also. Many thanks. I do have one question? Has your CI working pattern worked with any specific Wiggle Power, or have you not yet been able to establish that also?

AsDawnBreaks Lv 1

Agreed. What I find most interesting is walking being a good strategy, and needed because global wiggle doesn't resolve everything. However, the latest wiggle update did help that in my mind, or maybe it was just the puzzle I'm on.

karstenw Lv 1

I like the effort the devs have been making in trying to make the proteins wiggle to a position that is more accurate and provides better overall proteins. I am also hesitant to point out a problem where the devs are saying, "we know its tough this way, but it gives better results with the new wiggle function." I haven't the empirical data to base my next claim, which makes me even more reluctant.
I think wiggle is malfunctioning.
I understand that is meant to stop at a new optimal point that isn't reflected in the score per se, and so its stopping "sooner than it ought to", from a players perspective. But I also think its malfunctioning too. I think its essentially locking up at the tiniest dead ends that it comes across. Walking a protein is basically our way of doing deeper wiggles to squeeze out a point or two, but instead, we find that the wiggle can often be dislodged and 50 points can pop out.
Here's why this is a problem: after rebuilding a section of the protein, we will reject the the rebuild (and so will our scripts)if it scores lower than our previous build, but it may have 50 points still hiding in that new build that we were not aware of, thus the stone the builders rejected may well have been the corner stone.
There is a chance that all is working as intended. If so, then we will try to adapt to this new normal. Right now these are our concerns: 1.cpu power is high and computers are running slow and hot. 2.many are experiencing client crashes. 3.scripts are under performing while walkers are over performing 4.some puzzles like 854 are nearly unplayable do to filters being to constrictive 5.sticky wiggle 6.rebuild is better than before, but its still drunk. 7.(this one is my personal opinion) overall scoring is strange now, like hydrophilics that are scoring rather low on the outside of the protein. 8. it seems we are perpetually surrounded by local minimas, leaving our final proteins largely underdeveloped.
on a brighter note—love, love, love the idealize ss :)

gitwut Lv 1

Smilingone suggested using the Idealize SS tool to create helices last night. At first glance it looked like it worked great, but it doesn't easily or immediately create perfectly straight helices as we used to be able to.<p>
For one of my monomer (854) solutions I decided to do two simple helices. Without Idealize SS I was not able to get straight helices. After about an hour playing with it in combination with other tools I was finally able to get them straight, but it is not easy–at least not for me.<p>
Idealize SS is fine for just about straight and it is much improved since NC first came out, but it's still not good enough for easily designing monomers.

auntdeen Lv 1

Too many options, not enough clients to establish a new pattern yet :(

I do find that .2 and low plays out very quickly … On the other end, scripts run in high and 1.0 can still find many good points that were not there at 1.0 before.

I have no idea if I am using anything optimally yet!

AsDawnBreaks Lv 1

The new structure tool (currently in devprev) will take care of that. Idealize can help to make helixes, but that's not what it's designed for.

spmm Lv 1

Agreed gitwut - Idealise SS is better than nothing, but the ability to refine helixes, previously with quite a bit of precisely aimed effort, seems to be a distant memory.

gitwut Lv 1

AsDawnBreaks,

That is the tool I am talking about. It isn't always consistent, and in my tests the other night I had to struggle for a long time to be able to create perfectly straight helices with it using my final design as a starting point. I use the emphasis because today I started with the expired puzzle from scratch and was able to create both perfectly straight helices on the first attempt, bent them with wiggle and was able to use the tool to straighten them perfectly again.<p>
I'm still puzzled as to why it doesn't behave the same way in later stages of the puzzle. In my experimentation the other night, I also tried after changing all of the AAs to both ALA, and ILE but the resulting helices were still slightly bent. Perhaps one or more of the other attributes of the older helical segments remain unaltered by the tool and cause the slightly bent appearance? I don't know enough of the science behind the attributes.