Hi,
FYI, trailing whitespace can be easily eliminated by the sed in-place
substitution as follows, say to process all .F90 files in batch, do:
sed -i "s/\s\+$//g" *.F90
Similarly TABs can be replaced to other formats with a modification of
the regular expression.
Best,
Ruxi
On 4/17/17 15:40, David Cerutti wrote:
> Trailing whitespace is something that I've tried to get rid of, and I don't
> think that I've added any more so relative to the original code there
> should be a lot less. Something that I also want to tamp down on is
> LEADING whitespace versus TABs--my editor likes to auto-indent, and
> sometimes I worry this can appear as a TAB in other editors. What I may do
> is write a simple python script once I'm all done to eliminate the last
> trailing whitespace and make sure that the leading whitespace on every line
> is precisely that, so that everyone's editor sees exactly the same thing.
>
>
> On Mon, Apr 17, 2017 at 6:32 PM, David Cerutti <dscerutti.gmail.com> wrote:
>
>> Confirmed, code review has integrated the TI features from Ross's group.
>> I am working through the new kNLCPNE_AFE.h library, nearly done with that
>> as well. There is a good deal of code replication across libraries--not
>> just in the non-bonded routines of kNLCPNE but also in the particle--mesh
>> routines of kPSSE and related libraries. We might look into removing that
>> but at present the level is manageable.
>>
>> Future plans:
>> - Implement and test a lookup table for erfc(r)/r based on the base 2
>> logarithm of r2... it would work very much like pmemd CPU at that point,
>> but with a slightly different indexing system. One of those things that
>> just has to be tried to see whether it makes things faster but if lookups
>> from texture memory aren't terribly expensive it maintain the same accuracy
>> and save exp() and exp2f() in the inner loop.
>> - Implement an alternate pipeline for doing the dynamics calculation based
>> on the gemstones domain decomposition. A sorting method that keeps atoms
>> in both linear and local neighborhood formats, updated at every step, will
>> be central to this approach. Developers will then be able to choose
>> whether to work with the linear list of atoms or the domain decomposition
>> to implement new methods. The code will include numerous stencils for
>> importing groups of atoms into __shared__ memory which developers can use
>> to implement new energy functions or methods. Once things are in
>> __shared__ it's much easier for the uninitiated to write efficeint GPU
>> code, so the trick is to make an apparatus for getting there.
>>
>> Cheers,
>>
>> Dave
>>
>>
>> On Mon, Apr 17, 2017 at 6:18 PM, Charles Lin <clin92.ucsd.edu> wrote:
>>
>>> afaik the code review includes the ti code.
>>>
>>> -Charlie
>>>
>>> ________________________________________
>>> From: Ross Walker [rosscwalker.gmail.com] on behalf of Ross Walker [
>>> ross.rosswalker.co.uk]
>>> Sent: Monday, April 17, 2017 3:17 PM
>>> To: AMBER Developers Mailing List
>>> Cc: Daniel Mermelstein; Charles Lin
>>> Subject: Re: [AMBER-Developers] Code review of pmemd.cuda
>>>
>>> Hi Dave,
>>>
>>> Thanks for doing the code documentation. This will prove very helpful
>>> down the line. Modifying the whitespace though will potentially making
>>> patching a pain especially the TI code update. The beta is already built
>>> against AMBER 16 and, fortunately we have merged everything into master
>>> already. Additional betas will be a pain in the butt though since we'll
>>> have to maintain 2 versions of the code, one with the new whitespace and
>>> one that matches AMBER 16. We may end up having to provide tar files of the
>>> entire CUDA directory instead of a patch for future betas which is not
>>> ideal (it precludes us making the beta public) but that's something we'll
>>> have to figure out.
>>>
>>> Dan, Charlie - make sure you have all your latest changes merged into the
>>> master. Dave please work closely with Dan and Charlie to make sure this
>>> goes smoothly.
>>>
>>> We should also do a sanity check on performance and code correctness
>>> although from what you describe this should only be cosmetic changes yes?
>>>
>>> What do you have planned beyond the code review? We should coordinate
>>> things closely on this to make sure it doesn't conflict with what we plan
>>> running up to AMBER 18.
>>>
>>> All the best
>>> Ross
>>>
>>>> On Apr 17, 2017, at 6:00 PM, David Cerutti <dscerutti.gmail.com> wrote:
>>>>
>>>> To all:
>>>>
>>>> I am nearly finished with my code review of pmemd.cuda. Comments have
>>> been
>>>> added throughout with the goal of identifying every function's formal
>>>> arguments, clarifying the beginning and end of various long blocks of
>>> code,
>>>> and better documenting pre-processor directives with a long reach (i.e.
>>>> this #endif ends what?).
>>>>
>>>> While I have tried to preserve Scott's convention of extending
>>> assignment
>>>> statements to collect related variables into groups, a great deal of
>>> white
>>>> space has been removed in the interest of adhering to a strict
>>> 96-character
>>>> limit on each line. This will significantly increase the amount of code
>>>> that can fit on the screen at one time, and permit two or more terminal
>>>> windows to display separate libraries side by side for easy
>>>> cross-referencing. Spacing has also been added or removed to emphasize
>>> the
>>>> binding order of operations (I have a pretty detailed method, but please
>>>> don't feel that it is required for future commits). Additionally, I
>>> have
>>>> made an effort to decouple braces from pre-processor directives and
>>> provide
>>>> indentation for the pre-processor directives themselves to help
>>> developers
>>>> more easily gain a sense of where their code sits in very involved
>>> sections
>>>> like the non-bonded inner loops in kNLCPNE.h.
>>>>
>>>> IF YOU HAVE OUTSTANDING EDITS and need to commit them, I have made no
>>>> functional changes to the code quite yet--I wanted to get the review
>>> done
>>>> before I start making other changes. Please send me a mail directly if
>>> you
>>>> need to merge your items--it is straightforward to go back to the last
>>>> commit from two weeks ago and see the code as it was beforehand to make
>>> a
>>>> diff, but with the review nearly done I will help work out the best way
>>> to
>>>> do the merge.
>>>>
>>>> Cheers,
>>>> Dave
>>>> _______________________________________________
>>>> AMBER-Developers mailing list
>>>> AMBER-Developers.ambermd.org
>>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>
>>> _______________________________________________
>>> AMBER-Developers mailing list
>>> AMBER-Developers.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber-developers
>>>
>>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Apr 17 2017 - 16:30:03 PDT
