namot-general Mailing List for NAMOT-Nucleic Acid MOdelling Tool

Hi
i wanted to do a flexible docking and came across the Nucleic acid modeling
tool from the source forge.net
can any one help me with the installation process of this software in the
Linux machine
as i have not found any notes on the installation process of the tool.
thanks in advance please reply as soon as possible

with Regards
GOPALAKRISHNAN.R

Greetings,

A few weeks turned into a few months. I've released
namot-2.2.0-pre4. I expect this to be the last prerelease
before the full release. The major addition to this
version is amber7 reading and writting. The PDB I/O
has been updated as well. There are a few bug fixes 
which are described in the ChangeLog.

I don't have AMBER. I was given a few example files and 
made some guesses based on the amber data files available
for download. If anyone can test this functionality and
let me know one way or the other, I would be appreciative.

As I mention above, this should be the final pre-release.
If anyone has time to try any pet scripts, I'd appreciate
feedback.

I'll start writting the release notes and possibly a new
manual soon.

If anyone has any suggestions on where to advertise this new
release, let me know. 

Thanks,
Gene



On Mon, Aug 26, 2002 at 01:03:12PM -0400, Eugene Carter wrote:
> A pre-release of namot 2.2.0 is available at sourceforge.
> 
> I plan to wait at least a few weeks before declaring making a
> production release. I'm attaching a list of changes.
> 
> Let me know what you think,
> Gene
> 
> -- 
> Gene Carter
> Gradual Student in Neuroscience
> 



-- 
Gene Carter
Gradual Student in Neuroscience

A pre-release of namot 2.2.0 is available at sourceforge.

I plan to wait at least a few weeks before declaring making a
production release. I'm attaching a list of changes.

Let me know what you think,
Gene

-- 
Gene Carter
Gradual Student in Neuroscience

Greetings,

We're adding limited single stranded modelling capability to NAMOT.

SS NAMOT will be able to generate SS regions to fit
    -A specified distance
    -A general form(extended, random, stacked) 
    -A set of user supplied points(assuming they are of
     proper point-to-point distance).

We see the interface as working in terms of types of loops.

1. Isolated(non-attached)
    Requires the users to specify an end-to-end distance or a form.

2. Attached.
    a. single attachment point.
	-requires an end-to-end distance or form.
	-requires attachment point.
    b. double attachment. 
	-requires attachment points.
    c. Looped back to itself? 
	 
We also anticipate adding code to allow the user to specify a
curve in space with coordinates that represent a trace of
O3* and C5*.

Does this interface approach seem reasonable?

Gene

Greetings,

Courtesy of Erik, I'm spending the summer at CalTech working
on NAMOT(Before staring grad school at Brandeis in the fall
in Neuroscience). 

So far I've been doing mostly cleanup of the code. I've just started
looking at enhancements. This evening, I peaked at using swig(www.swig.org)
to create a python interface.

Within an hour I generated a double helix and dumped PDB co-ordinates
from python(no GUI). I'm fairly encouraged by this and will start
work tommorrow on the real extension process. I probably won't
have time to embed. It is problably trivial to build a 
GUI around the extended python module, so embedding may become
a moot point.

The namot CVS area on sourceforge is getting updated almost daily,
in case anyone wants to take a look/try it out.

If anyone needs any bug fixes, or has suggestions for features,
now is the time to let me know.

Gene

-- 
Achbar blee haloneem

I spent the weekend looking at python. Despite the ick of 
manual indention(which has its benifits too), I think Python
is a good choice as the scripting language for NAMOT.

That being decided, pyMol becomes almost any automatic choice. 

I'm going to contact Dr DeLano for his thoughts on linking
NAMOT and pyMol.

Thanks for your input.

Gene
On Wed, Mar 20, 2002 at 01:06:22PM -0800, Peter C. McCluskey wrote:
> 
>  ec...@mi... (Gene Carter) writes:
> >There does appear to be more support and money for continued
> >VMD development whereas pyMol appears to be two guys and a
> >sourceforge account. The game here is to guess which one is
> >likely to stay maintained the longest.
> 
>  I've looked at both in the past, but I haven't tried to do anything
> interesting with either one, so I only have vague guesses as to which
> is more powerful. My opinion is that pyMol is probably a better choice.
>  The pyMol installation was easy enough that I'm fairly sure it was
> designed to be portable. Whereas the VMD installation from source code
> had enough problems that I gave up on it (I'm sure I could have gotten
> it working with enough motivation). This suggests to me that the effort
> required to keep VMD compatible with new systems is likely to be a good
> deal higher than the maintainance that pyMol would need.
>  While the group behind VMD is probably a good deal more predictable
> than DeLano Scientific, pyMol doesn't look like the kind of product that
> would be abandoned quickly. Also, the pyMol license makes it easy for
> anyone to take over it's maintainance. Whereas if the VMD group loses
> interest in VMD, their restrictive license probably prevents anyone
> else from redistributing updated versions. There's no guarantee that
> new users could even get copies of any VMD version if the VMD group
> shut down the web page that asks users to register. I don't want to use
> something with that kind of license if I have a good alternative.
> -- 
> ------------------------------------------------------------------------------
> Peter McCluskey          | Free Jon Johansen!
> http://www.rahul.net/pcm | 
> 
> _______________________________________________
> namot-general mailing list
> nam...@li...
> https://lists.sourceforge.net/lists/listinfo/namot-general

-- 
Achbar blee haloneem

 ec...@mi... (Gene Carter) writes:
>There does appear to be more support and money for continued
>VMD development whereas pyMol appears to be two guys and a
>sourceforge account. The game here is to guess which one is
>likely to stay maintained the longest.

 I've looked at both in the past, but I haven't tried to do anything
interesting with either one, so I only have vague guesses as to which
is more powerful. My opinion is that pyMol is probably a better choice.
 The pyMol installation was easy enough that I'm fairly sure it was
designed to be portable. Whereas the VMD installation from source code
had enough problems that I gave up on it (I'm sure I could have gotten
it working with enough motivation). This suggests to me that the effort
required to keep VMD compatible with new systems is likely to be a good
deal higher than the maintainance that pyMol would need.
 While the group behind VMD is probably a good deal more predictable
than DeLano Scientific, pyMol doesn't look like the kind of product that
would be abandoned quickly. Also, the pyMol license makes it easy for
anyone to take over it's maintainance. Whereas if the VMD group loses
interest in VMD, their restrictive license probably prevents anyone
else from redistributing updated versions. There's no guarantee that
new users could even get copies of any VMD version if the VMD group
shut down the web page that asks users to register. I don't want to use
something with that kind of license if I have a good alternative.
-- 
------------------------------------------------------------------------------
Peter McCluskey          | Free Jon Johansen!
http://www.rahul.net/pcm | 

Greetings,

I recently met with Erik's group, from those discussions it appears that
NAMOT would be more useful if certain graphics capabilities were present.
In particular support for shutter glasses and possibly other VR accoutrement.

I would rather not add this support directly to NAMOT. What I'd like to
do is add an interface so that NAMOT can talk directly to a molecular
visualization program.

I've done a quick review and there seems to be two programs which might
be good canidates to write the interface towards. I'm sending this
out to the list to gather opinions before I spend too much time
on this.

The two packages are VMD and pyMol. Most of you are probably familar
with VMD. My starting point for modification would be the interactive
molecular dynamics protocol. The limitation there is that VMD requires
that the primary structure not change. I would work out a "refresh"
of sorts where changes in primary structure get communicated between
the two engines.

pyMol is a python-enhanced molecular viewer. I haven't looked at
this one too closely. 

There does appear to be more support and money for continued
VMD development whereas pyMol appears to be two guys and a
sourceforge account. The game here is to guess which one is
likely to stay maintained the longest.

Thoughts?

Gene

-- 
Achbar blee haloneem

Test of namot-general mail list.

-- 
Achbar eem haloneem lifameem!
Rat with Windows Sometimes.

This is an attempt at using the namot-general list.


-- 
Achbar eem haloneem lifameem!
Rat with Windows Sometimes.

test email.

-- 
Achbar eem haloneem lifameem!
Rat with Windows Sometimes.

Neha,

The mail list appears not to be working. I've opened a ticket
with SourceForge to get it examined.

H:U:B would definately be more useful in cases where the
users was working with a molecule which NAMOT recoginizes
as a nucleic acid. However, it wouldn't help in the case
of non-nucliec acids. I'd like a solution which was a
bit more general.

The reason M:C:G was used, is because ultimately, you
are moving the M:C:G heirarchy, not the H:U:B heirarchy.

All that being said, I don't expect any difficulty
making the nick/link use H:U:B. 

The current source set I'm working with is pretty different
structurally from the NAMOT you have. I've gone back and
    -added PNG support
    -added readline support 
    -removed the xview and tiff code
    -added return codes to most functions
    -added python into the compile, but its currently
     not used.
    -added more error checking on the mallocs.

My short list of things to do...
    -adding an "error stack" sort of system which would
     really be of value for the python support.
    -cleaning up the code in terms of making sure all
     errors(malloc, etc) are caught and handled.
    -python integration. 

Would you like this newer version, or do you want a patch
for the older version? You should be warned that I haven't
run it through my test scripts yet.

Gene

On Wed, Aug 15, 2001 at 03:52:45PM -0700, Neha Soni wrote:
> 
> 
> Hi,
> 
> I'm working on writing a program that accepts user input in a specific
> format, and
> automatically generates the namot script for the molecule (molecules like
> DAO, DAE, DPE, even more general ones with parallel helix axes)
> 
> I was wondering if it is feasible/usefule to let namot accept commands
> like 'nick' and 'link', using the H:U:B format, in addition to the present
> M:C:G format?
> 
> It seems like it may be easier for the user, for example, to link two
> strands using H:U:B, since that the H, U, B values do not change after
> nicking and linking
> strands together. Is there a reason why M:C:G is preferred? How hard is it
> to make the change?
> 
> -Neha

-- 
Achbar eem haloneem lifameem!
Rat with Windows Sometimes.

Test of list. 

-- 
Achbar eem haloneem lifameem!
Rat with Windows Sometimes.

Hi,

I'm working on writing a program that accepts user input in a specific
format, and
automatically generates the namot script for the molecule (molecules like
DAO, DAE, DPE, even more general ones with parallel helix axes)

I was wondering if it is feasible/usefule to let namot accept commands
like 'nick' and 'link', using the H:U:B format, in addition to the present
M:C:G format?

It seems like it may be easier for the user, for example, to link two
strands using H:U:B, since that the H, U, B values do not change after
nicking and linking
strands together. Is there a reason why M:C:G is preferred? How hard is it
to make the change?

-Neha