text:
When opening images from digital cameras, Adobe® Photoshop® Elements 2.0 reads the ICC color profile and EXIF metadata supplied by the camera to determine which color space it should use to interpret each image. Certain digital cameras do not embed ICC profiles and always specify the sRGB color space in the EXIF data, even though they allow the photographer to use different spaces. As a result, Photoshop Elements behaves as if each image is tagged with an sRGB ICC profile.
Placing the plug-in called Ignore EXIF Color Space into the Adobe Photoshop Elements 2 Plug-Ins folder will instruct Photoshop Elements to ignore the color space specified in EXIF metadata. In this mode, Photoshop Elements will ignore the EXIF color space. Photoshop Elements will continue to ignore the EXIF color space setting in files unless the plug-in is removed and Photoshop Elements is restarted.
|Photoshop Elements
|File Name
|File Size
|Proceed to Download
Adobe Photoshop Elements 2.0 for Mac OS
After downloading a ".hqx" file on a Macintosh, use StuffIt Deluxe or StuffIt Expander to access the file's contents. StuffIt Expander is available as a freeware product.
NOTE: Please ensure you have the latest version of StuffIt by Allume Systems, Inc.
Need help with downloading? See our Downloading Help documents.
1. Make sure Adobe Photoshop Elements 2.0 is not running.
2. Download the archive file that contains the Ignore EXIF Color Space plug-in.
3. Use StuffIt Deluxe or StuffIt Expander to extract the contents of the archive file.
4. Locate the Adobe Photoshop Elements 2:Plug-Ins:Extensions folder.
5. Drag the extracted Ignore EXIF Color Space plug-in into the Extensions folder within the Plug-Ins folder.
6. Launch Photoshop Elements 2.0.
License agreement
By using software of Adobe Systems Incorporated or its subsidiaries ("Adobe"); you agree to the following terms and conditions. If you do not agree with such terms and conditions; do not use the software. The terms of an end user license agreement accompanying a particular software file upon installation or download of the software shall supersede the terms presented below.
The export and re-export of Adobe software products are controlled by the United States Export Administration Regulations and such software may not be exported or re-exported to Cuba; Iran; Iraq; Libya; North Korea; Sudan; or Syria or any country to which the United States embargoes goods. In addition; Adobe software may not be distributed to persons on the Table of Denial Orders; the Entity List; or the List of Specially Designated Nationals.
By downloading or using an Adobe software product you are certifying that you are not a national of Cuba; Iran; Iraq; Libya; North Korea; Sudan; or Syria or any country to which the United States embargoes goods and that you are not a person on the Table of Denial Orders; the Entity List; or the List of Specially Designated Nationals.
If the software is designed for use with an application software product (the "Host Application") published by Adobe; Adobe grants you a non-exclusive license to use such software with the Host Application only; provided you possess a valid license from Adobe for the Host Application. Except as set forth below; such software is licensed to you subject to the terms and conditions of the End User License Agreement from Adobe governing your use of the Host Application.
DISCLAIMER OF WARRANTIES: YOU AGREE THAT ADOBE HAS MADE NO EXPRESS WARRANTIES TO YOU REGARDING THE SOFTWARE AND THAT THE SOFTWARE IS BEING PROVIDED TO YOU "AS IS" WITHOUT WARRANTY OF ANY KIND. ADOBE DISCLAIMS ALL WARRANTIES WITH REGARD TO THE SOFTWARE; EXPRESS OR IMPLIED; INCLUDING; WITHOUT LIMITATION; ANY IMPLIED WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE; MERCHANTABILITY; MERCHANTABLE QUALITY OR NONINFRINGEMENT OF THIRD PARTY RIGHTS. Some states or jurisdictions do not allow the exclusion of implied warranties; so the above limitations may not apply to you.
LIMIT OF LIABILITY: IN NO EVENT WILL ADOBE BE LIABLE TO YOU FOR ANY LOSS OF USE; INTERRUPTION OF BUSINESS; OR ANY DIRECT; INDIRECT; SPECIAL; INCIDENTAL; OR CONSEQUENTIAL DAMAGES OF ANY KIND (INCLUDING LOST PROFITS) REGARDLESS OF THE FORM OF ACTION WHETHER IN CONTRACT; TORT (INCLUDING NEGLIGENCE); STRICT PRODUCT LIABILITY OR OTHERWISE; EVEN IF ADOBE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Some states or jurisdictions do not allow the exclusion or limitation of incidental or consequential damages; so the above limitation or exclusion may not apply to you.


text:
I truly appreciate the fact that a State Agency is monitoring our community to get feedback and address operational issues. This is a great example of DPS' commitment to LTCs. When processing tens of thousands of applications monthly, far more than they are staffed to handle, some anomalies are bound to occur. The LTC Division is doing everything they can to minimize problems and to address them quickly when they arise. Thanks DPS!
DPS wrote:From time to time, I go out to TexasCHLforum.com and see what is being said about DPS and our program. I noticed the chatter about "change of address"(COA). I have noticed we have had an issue with the COA recently. Some are going through, some are not. Normally, when someone does the COA online, the license is printed within 2 business days. If it is taking over 10-14 business days to get the new license, they should call in and get an update.

subset: commoncrawl


text:
Department of Human Evolution
Max Planck Institute for Evolutionary Anthropology
Deutscher Platz 6
04103 Leipzig
phone: +49 (341) 3550 - 350
fax: +49 (0341) 3550 - 399
e-mail: streiber@[>>> Please remove the brackets! <<<]eva.mpg.de
Karen Ruebens
Post-Doctoral Researcher
Max Planck Institute for Evolutionary Anthropology
Department of Human Evolution
Deutscher Platz 6
04103 Leipzig
phone: 0049 (0) 341 3550 364
fax: 0049 (0) 341 3550 399
e-mail: karen_ruebens@[>>> Please remove the brackets! <<<]eva.mpg.de
Research Interests
I am a postdoctoral researcher specialised in Palaeolithic archaeology and lithic analyses aimed at understanding patterns underlying human evolution with specific emphasis on Neanderthal behaviour. My current research focuses on Middle Palaeolithic lithic variability, in particular assessing region-specific trends across Europe to understand the causes, mechanisms and behavioural implications of changes in lithic technology, including across the Middle to Upper Palaeolithic transition.
I re-joined the Human Evolution department in 2017 with a Marie Skłodowska-Curie Career Restart Fellowship. My MSC project 'TIP-N-POINT' focuses on reconstructing the technology underlying Middle Palaeolithic hunting events though an assemblage level assessment of the role of point shapes in the Neanderthal tool kit. It is aimed to bridge review and primary assemblage level data across Europe as well as applying a suite of analytical tools, including geometric morphometrics, GIS edge damage mapping and quantitative approaches (incl. generalised linear modelling).


text:
Sending a steel ball speeding across a tilted board studded with bumpers can be an addictive pastime—a tantalizing blend of skill to keep the ball in play and unpredictability in the ball's erratic path, rebound by rebound.
The pinball machine can serve as a model of deterministic chaos—a system that embodies a sensitive dependence on initial conditions. Balls with slightly different starting points end up following very different paths when they ricochet through the array of bumpers. Moreover, any uncertainty in a ball's initial position makes it difficult to predict where the ball will be even after just a few bounces.
Mathematician Henri Poincaré introduced this notion of "sensitive dependence on initial conditions" in the early part of the 20th century, when he tangled with the intricacies of predicting planetary motion.
In his 1908 essay "Science and Method," Poincaré wrote, ". . . it may happen that small differences in the initial conditions produce very great ones in the final phenomena. A small error in the former will produce an enormous error in the latter. Prediction becomes impossible, and we have the fortuitous phenomenon."
Decades later, mathematician and meteorologist Edward N. Lorenz discovered the same effect embodied in equations used to model weather systems. At a meeting in 1972 he presented a paper with the provocative title "Does the Flap of a Butterfly's Wings in Brazil Set Off a Tornado in Texas?"
"I avoided answering the question," he writes in his 1993 autobiography, The Essence of Chaos, "but noted that if a single flap could lead to a tornado that would not otherwise have formed, it could equally well prevent a tornado that would otherwise have formed."
Nonetheless, the term "butterfly effect" soon entered the lexicon to describe the unpredictable, even potentially drastic, consequences of a small change.
Lorenz also tells a story about pinball machines—the earlier kind without flippers or flashing lights, with nothing but arrays of pins to disturb the motion of the ball.
One spring in the 1930s during his undergraduate years at Dartmouth College, Lorenz recounts, a few pinball machines appeared in local drugstores and eateries.
"Soon many students were occasionally winning, but more often losing, considerable numbers of nickels," he writes. "Before long the town authorities decided that the machines violated the gambling laws and would have to be removed, but they were eventually persuaded, temporarily at least, that the machines were contests of skill rather than games of chance, and were therefore perfectly legal."
If that were true, however, students should have been able to perfect their skills and become regular winners, Lorenz notes. That didn't happen because of the deterministic chaos inherent in the pinball machine.
The Exploratorium in San Francisco gives you two chances to study pinball chaos. The Tinkering Studio includes a do-it-yourself model, where you can place various objects in different positions on a sloping table to investigate their effect on the trajectories of spring-projected balls.
Controlling just the initial speed of the ball, it is remarkably difficult to get a ball to follow the same path and come to rest at a given location at the bottom, even with just a few circular bumpers on the table.
Not too far away, you can also try your skill on arcade-style pinball, but with an Exploratorium twist. You don't need any coins to play, and the sides of the machine are transparent so that you can see what goes on inside.
Lorenz, E.N. 1993. The Essence of Chaos. University of Washington Press.
Peterson, I. 1993. Newton's Clock: Chaos in the Solar System. W.H. Freeman.
______. 1990. Islands of Truth: A Mathematical Mystery Cruise. W.H. Freeman.
Photos by I. Peterson


text:
National ID
We must stop the move toward a national ID card system. All states are preparing to issue new driver's licenses embedded with "standard identifier" data – a national ID. A national ID with new tracking technologies means we're heading into an Orwellian world of no privacy.
Over the many years there have been numerous attempts to implement a national ID card.
Randy salutes and supports Ron Paul's efforts, though the years, to fend off this repeated attempt to invade our civil liberties! See the twists and turns the fight has taken in the last 12 years:
Legislation brought forward to stop National ID (July 15, 1998)
In response to a national outcry against Department of Transportation rules to establish a national ID system by the first of October, in the year 2000, US Rep. Ron Paul (R-Texas) on Wednesday introduced the Freedom and Privacy Restoration Act, HR4217. Rep. Bob Barr (R-Georgia) is an original cosponsor of the bill.
Paul leads effort to stop National ID (June 24, 1999)
Calling on the federal government to end its war on the privacy rights of American citizens and the prerogatives of state governments, US Rep. Ron Paul (R, Texas) is leading a bipartisan team attempting to stop the national ID card, which is set for implementation on Oct. 1, 2000.
National ID killed by House (October 1, 1999)
In approving the House-Senate compromise on the Transportation Appropriations legislation Friday, the House of Representatives killed an ill-conceived plan that would have prevented Americans from getting new jobs, boarding airplanes or exercising their Second Amendment rights without holding a National ID card. The National ID was slated to go into effect Oct. 1, 2000.
Reject the National ID Card (September 6, 2004)
The much-hailed 9/11 Commission report released in July recommends a federal identification card and, worse, a "larger network of screening points" inside the United States. Does this mean we are to have "screening points" inside our country where American citizens will be required to "show their papers" to government officials? It certainly sounds that way!
Paul Denounces National ID Card (December 7, 2004)
Congressman Ron Paul today denounced the national ID card provisions contained in the intelligence bill being voted on in the U.S. House of Representatives, while urging his colleagues to reject the bill and its new layers of needless bureaucracy. "National ID cards are not proper in a free society," Paul stated. "This is America, not Soviet Russia. The federal government should never be allowed to demand papers from American citizens, and it certainly has no constitutional authority to do so."
A National ID Bill Masquerading as Immigration Reform (February 9, 2005)
I rise in strong opposition to HR 418, the REAL ID Act. This bill purports to make us safer from terrorists who may sneak into the United States, and from other illegal immigrants. While I agree that these issues are of vital importance, this bill will do very little to make us more secure. It will not address our real vulnerabilities. It will, however, make us much less free. In reality, this bill is a Trojan horse. It pretends to offer desperately needed border control in order to stampede Americans into sacrificing what is uniquely American: our constitutionally protected liberty. What is wrong with this bill? The REAL ID Act establishes a national ID card by mandating that states include certain minimum identification standards on driver's licenses. It contains no limits on the government's power to impose additional standards. Indeed, it gives authority to the Secretary of Homeland Security to unilaterally add requirements as he sees fit.
National ID Cards Won't Stop Terrorism or Illegal Immigration (May 9, 2005)
This REAL ID Act establishes a massive, centrally-coordinated database of highly personal information about American citizens: at a minimum their name, date of birth, place of residence, Social Security number, and physical characteristics. The legislation also grants open-ended authority to the Secretary of Homeland Security to require biometric information on IDs in the future. This means your harmless looking driver's license could contain a retina scan, fingerprints, DNA information, or radio frequency technology.
A National ID Card? Outrageous! (March 10, 2010)
Ron Paul explains on Fox News why he is opposed to a national ID card: "To me it violates the whole principles of privacy, the principles of the Constitution, the principles of the Republic and to me that's a gross distortion of what we should be doing. It's part of an authoritarian society and dictatorships have this but not a republic. We're not supposed to have that…"


text:
The Nationwide series kicks off the weekend tonight at Richmond International Raceway. Travis Pastrana is set to hop back in the saddle once again to make his Nationwide debut, after is was postponed due to an X Games accident at the Los Angeles Arena last year while doing a trick on his dirt bike.
His ankle was shattered into about 20 pieces during that accident, so it wasn't your typical break. It has taken Pastrana about 9 months to recover from his injuries and countless hours of rehab.
Travis said that he has been spending a ton of time in the iRacing Machine track simulator, to try to prepare for the Virginia 529 College Savings 250 that will run tonight at RIR.
Pastrana also went on to say that he's a little more prepared now then he would have been last year, and that he didn't fully understand the language that the drivers use to describe set-ups and how the car may be handling. During his time off he watched more of the sport to educate himself on what the drivers were talking about when describing different scenarios and situations.
Another thing that they had to fix was, when Travis sat in the cock pit of his race car they had to relocate the gas pedal in relation to his repaired ankle so that he could get on and off of the throttle easier while out on the race track.
He said that he would he happy to finish his first race and to stay out of trouble by not hitting the wall or a fellow competitor.


text:
B.J. Hoeptner Evans
Manager, Media Relations and Publications
Phone: (719) 228-6800
E-Mail: email@example.com
COLORADO SPRINGS, Colo. (April 13, 2011) – It's another week of updates on U.S. Men's National and A2 Team players competing around the world.
Iraklis, including U.S. opposite Brook Billings (Santa Barbara, Calif.) and outside hitter Ryan Owens (Evanston, Ill.), will face outside hitter Jayson Jablonsky (Yorba Linda, Calif.) and Olympiakos in the finals of the Hellenic league playoffs.
Iraklis qualified for the finals by winning two straight semifinal matches against U.S. setter Jonathan Winder (Irvine, Calif.) and PAOK.
After taking a 3-2 victory in the first playoff match on April 6, Iraklis swept the second match, 25-23, 25-20, 25-16 on April 9.
Owens led all scorers with 14 points on eight kills (0.43 hitting percentage), two blocks and a match-high four aces. He was credited with eight receptions, 83 percent positive and 50 percent excellent. Billings added 11 points on seven kills, two blocks and two aces. Winder started the first two sets and did not score. He helped set the team to a 0.35 hitting percentage.
Olympiakos advanced with two straight semifinal victories over Panathinaikos. Olympiakos won the first match, 3-2 on April 6. It won the second match 18-25, 20-25, 25-17, 25-19, 16-14 on April 9. After substituting in the first two sets, Jablonsky started the final three sets and scored 10 points on 10 kills (0.67 hitting percentage). He was credited with 14 receptions, 57 percent positive and 14 percent excellent.
The best-of-five championship series will begin April 27.
U.S. outside hitter Sean Rooney (Wheaton, Ill.) and his Italian Serie A league team Acqua Paradiso Monza Brianza are 2-1 in the best-of-five playoff quarterfinals against Casa Modena.
After winning the first match 3-1 on April 7, Monza Brianza lost the second match, 25-18, 29-27, 25-15. Rooney scored seven points on six kills and one ace. He was credited with 20 receptions, 40 percent positive and 10 percent excellent.
Monza Brianza won the third match on April 14, 25-16, 17-25, 22-25, 25-22, 15-12. Rooney scored 20 points on 19 kills (0.56 hitting percentage) and one block. He was credited with 32 receptions, 56 percent positive and 25 percent excellent.
The teams will play again on April 17.
U.S. middle blocker Russell Holmes (Fountain Valley, Calif.) and his Brazilian Superleague team Vivo/Minas lost the third and deciding match in their semifinal playoff series against Sesi-SP.
Vivo/Minas fell 25-20, 26-24, 25-23 on April 8. Holmes played as a substitute and started the third set, scoring two points.
U.S. middle blocker Ryan Millar (Alpine, Utah) and his Polish league team Asseco Resovia Rzeszów will play for third place in the league after losing the semifinal playoff series 3-1 to ZAKSA Kędzierzyn-Koźle.
Resovia Rzeszów lost the final match 25-20, 20-25, 25-15, 25-23. Millar scored nine points on four kills and five blocks.
In their first third-place match on April 13, Millar and Resovia Rzeszów defeated Tytan AZS Częstochowa, 16-25, 25-16, 15-25, 25-23, 15-11. Millar scored seven points on five kills, one block and one ace.
Fart Kielce, including U.S. libero Rich Lambourne (Tustin, Calif.) began a best-of-seven series against Pamapol Wielton Wieluń to determine the league's ninth-place finisher on April 13.
Kielce fell 25-23, 25-16, 25-27, 12-25, 15-11. Lambourne was credited with with 42 receptions, 52 percent positive and 38 percent excellent. The series will continue on April 16.
U.S. outside hitter Scott Touzinsky (St. Louis, Mo.) and his German league team SCC Berlin have won the first two matches of their playoff quarterfinals series against RWE Volleys Bottrop.
On April 9, Berlin defeated Bottrop, 25-23, 21-25, 25-14, 25-14. Touzinsky started the first two sets and scored three points on three kills.
On April 12, Berlin topped Bottrop, 25-15, 21-15, 26-24, 20-25, 15-11. Touzinsky played all five sets, scoring 16 points on 16 kills (0.46 hitting percentage). He was credited with 27 receptions, 52 percent positive and 33 percent excellent.
The teams will play again on April 17.
U.S. opposite Evan Patak (Pleasanton, Calif.) and his Korean league team Korean Air lost their best-of-seven championship series against Samsung in four matches.
KAL lost the fourth match on April 9, 25-22, 17-25, 25-18, 23-25, 15-12.
Patak led KAL with 39 points on 36 kills and three aces. However, Canada's Gavin Schmitt, who plays for Samsung, led all scorers with 53 points.
U.S. setter Brian Thornton (San Clemente, Calif.) and outside hitter Eric Vance (Camarillo, Calif.) and their French B league team Chaumont defeated CNVB, 33-31, 25-22, 25-18. Vance started the first set and scored four points on four kills. Thornton scored one point on an ace and set the team to a 0.60 kill percentage.


text:
From NWChem
Top-level Directives
Top-level directives are directives that can affect all modules in the code. Some specify molecular properties or other data that should apply to all subsequent calculations with the current database. However, most top-level directives provide the user with the means to manage the resources for a calculation and to start computations. As the first step in the execution of a job, NWChem scans the entire input file looking for start-up directives, which NWChem must process before all other input. The input file is then rewound and processed sequentially, and each directive is processed in the order in which it is encountered. In this second pass, start-up directives are ignored.
The following sections describe each of the top-level directives in detail, noting all keywords, options, required input, and defaults.
The START or RESTART directive define the start-up mode and are optional keywords. If one of these two directives is not specified explicitly, the code will infer one, based upon the name of the input file and the availability of the database. When allowing NWChem to infer the start-up directive, the user must be quite certain that the contents of the database will result in the desired action. It is usually more prudent to specify the directive explicitly, using the following format:
(RESTART || START) [<string file_prefix default input_file_prefix>] \ [rtdb <string rtdb_file_name default file_prefix.db>]
The START directive indicates that the calculation is one in which a new database is to be created. Any relevant information that already exists in a previous database of the same name is destroyed. The string variable <file_prefix> will be used as the prefix to name any files created in the course of the calculation.
E.g., to start a new calculation on water, one might specify
start water
which will make all files begin with "water.".
If the user does not specify an entry for <file_prefix> on the START directive (or omits the START directive altogether), the code uses the base-name of the input file as the file prefix. That is, the variable <file_prefix> is assigned the name of the input file (not its full pathname), but without the last "dot-suffix". For example, the input file name /home/dave/job.2.nw yields job.2 as the file prefix, if a name is not assigned explicitly using the START directive.
The user also has the option of specifying a unique name for the database, using the keyword rtdb. When this keyword is entered, the string entered for rtdb_file_name is used as the database name. If the keyword rtdb is omitted, the name of the database defaults to file_prefix.db in the directory for permanent files.
If a calculation is to start from a previous calculation and go on using the existing database, the RESTART directive must be used. In such a case, the previous database must already exist. The name specified for <file_prefix> usually should not be changed when restarting a calculation. If it is changed, NWChem will not be able to find needed files when going on with the calculation.
In the most common situation, the previous calculation was completed (with or without an error condition), and it is desired to perform a new task or restart the previous one, perhaps with some input changes. In these instances, the RESTART directive should be used. This re-uses the previous database and associated files, and reads the input file for new input and task information.
The RESTART directive looks immediately for new input and task information, deleting information about previous incomplete tasks. For example, when doing a RESTART there is no need to specify geometry or basis set declaration because the program will detect this information since it is stored in the run-time database.
If a calculation runs out of time, for example because it is on a queuing system, this is another instance where doing a RESTART is advisable. Simply include nothing after the RESTART directive except those tasks that are unfinished.
To summarize the default options for this start-up directive, if the input file does not contain a START or a RESTART directive, then
- the variable <file_prefix> is assigned the name of the input file for the job, without the suffix (which is usually .nw)
- the variable <rtdb_file_name> is assigned the default name, file_prefix.db
If the database with name file_prefix.db does not already exist, the calculation is carried out as if a START directive had been encountered. If the database with name file_prefix.db does exist, then the calculation is performed as if a RESTART directive had been encountered.
For example, NWChem can be run using an input file with the name water.nw by typing the UNIX command line,
nwchem water.nw
If the NWChem input file water.nw does not contain a START or RESTART directive, the code sets the variable <file_prefix> to water. Files created by the job will have this prefix, and the database will be named water.db. If the database water.db does not exist already, the code behaves as if the input file contains the directive,
start water
If the database water.db does exist, the code behaves as if the input file contained the directive,
restart water
This start-up directive allows the user to specify the directory location of permanent files created by NWChem. NWChem distinguishes between permanent (or persistent) files and scratch (or temporary) files, and allows the user the option of putting them in different locations. In most installations, however, permanent and scratch files are all written to the current directory by default. What constitutes "local" disk space may also differ from machine to machine.
The PERMANENT_DIR directives enable the user to specify a single directory for all processes or different directories for different processes. The general form of the directive is as follows:
(PERMANENT_DIR) [(<string host&>||<integer process>):] <string directory> [...]
This start-up directive allows the user to specify the directory location of scratch files created by NWChem. NWChem distinguishes between permanent (or persistent) files and scratch (or temporary) files, and allows the user the option of putting them in different locations. In most installations, however, permanent and scratch files are all written to the current directory by default. What constitutes "local" disk space may also differ from machine to machine.
The conventions for file storage are at the discretion of the specific installation, and are quite likely to be different on different machines. When assigning locations for permanent and scratch files, the user must be cognizant of the characteristics of the installation on a particular platform. To consider just a few examples, on clusters, machine-specific or process-specific names must be supplied for both local and shared file systems, while on SMPs it is useful to specify scratch file directories with automated striping across processors with round-robin allocation. On SMP clusters (a.k.a. constellations), both of these specifications are required.
The SCRATCH_DIR enables the user to specify a single directory for all processes or different directories for different processes. The general form of the directive is as follows:
(SCRATCH_DIR) [(<string host&>||<integer process>):] <string directory> [...]
Directories are extracted from the user input by executing the following steps, in sequence:
- Look for a directory qualified by the process ID number of the invoking process. Processes are numbered from zero. Else,
- If there is a list of directories qualified by the name of the host machineAs returned by util_hostname() which maps to the output of the command hostname on Unix workstations., then use round-robin allocation from the list for processes executing on the given host. Else,
- If there is a list of directories unqualified by any hostname or process ID, then use round-robin allocation from this list.
If directory allocation directive(s) are not specified in the input file, or if no match is found to the directory names specified by input using these directives, then the steps above are executed using the installation-specific defaults. If the code cannot find a valid directory name based on the input specified in either the directive(s) or the system defaults, files are automatically written to the current working directory (".").
The following is a list of examples of specific allocations of scratch directory locations:
- Put scratch files from all processes in the local scratch directory (Warning: the definition of "local scratch directory" may change from machine to machine):
scratch_dir /localscratch
- Put scratch files from Process 0 in /piofs/rjh, but put all other scratch files in /scratch:
scratch_dir /scratch 0:/piofs/rjh
- Put scratch files from Process 0 in directory scr1, those from Process 1 in scr2, and so forth, in a round-robin fashion, using the given list of directories:
scratch_dir /scr1 /scr2 /scr3 /scr4 /scr5
- Allocate files in a round-robin fashion from host-specific lists for processes distributed across two SGI multi-processor machines (node names coho and bohr):
scratch_dir coho:/xfs1/rjh coho:/xfs2/rjh coho:/xfs3/rjh bohr:/disk01/rjh bohr:/disk02/rjh bohr:/disk13/rjh
This is a start-up directive that allows the user to specify the amount of memory PER PROCESSOR CORE that NWChem can use for the job. If this directive is not specified, memory is allocated according to installation-dependent defaults. The defaults should generally suffice for most calculations, since the defaults usually correspond to the total amount of memory available on the machine.
The general form of the directive is as follows:
MEMORY [[total] <integer total_size>] \ [stack <integer stack_size>] \ [heap <integer heap_size>] \ [global <integer global_size>] \ [units <string units default real>] \ [(verify||noverify)] \ [(nohardfail||hardfail)]
NWChem recognizes the following memory units:
- real and double (synonyms)
- integer
- real and double (synonyms)
- integer
- byte
- kb (kilobytes)
- mb (megabytes)
- mw (megawords, 64-bit word)
In most cases, the user need specify only the total memory limit to adjust the amount of memory used by NWChem. The following specifications all provide for eight megabytes of total memory (assuming 64-bit floating point numbers), which will be distributed according to the default partitioning:
memory 1048576 memory 1048576 real memory 1 mw memory 8 mb memory total 8 mb memory total 1048576
In NWChem there are three distinct regions of memory: stack, heap, and global. Stack and heap are node-private, while the union of the global region on all processors is used to provide globally-shared memory. The allowed limits on each category are determined from a default partitioning (currently 25% heap, 25% stack, and 50% global). Alternatively, the keywords stack, heap, and global can be used to define specific allocations for each of these categories. If the user sets only one of the stack, heap, or global limits by input, the limits for the other two categories are obtained by partitioning the remainder of the total memory available in proportion to the weight of those two categories in the default memory partitioning. If two of the category limits are given, the third is obtained by subtracting the two given limits from the total limit (which may have been specified or may be a default value). If all three category limits are specified, they determine the total memory allocated. However, if the total memory is also specified, it must be larger than the sum of all three categories. The code will abort if it detects an inconsistent memory specification.
The following memory directives also allocate 8 megabytes, but specify a complete partitioning as well:
memory total 8 stack 2 heap 2 global 4 mb memory stack 2 heap 2 global 4 mb
The optional keywords verify and noverify in the directive give the user the option of enabling or disabling automatic detection of corruption of allocated memory. The default is verify, which enables the feature. This incurs some overhead (which can be around 10% increase in walltime on some platforms), which can be eliminated by specifying noverify.
The keywords hardfail and nohardfail give the user the option of forcing (or not forcing) the local memory management routines to generate an internal fatal error if any memory operation fails. The default is nohardfail, which allows the code to continue past any memory operation failure, and perhaps generate a more meaningful error message before terminating the calculation. Forcing a hard-fail can be useful when poorly coded applications do not check the return status of memory management routines.
When assigning the specific memory allocations using the keywords stack, heap, and global in the MEMORY directive, the user should be aware that some of the distinctions among these categories of memory have been blurred in their actual implementation in the code. The memory allocator (MA) allocates both the heap and the stack from a single memory region of size heap+stack, without enforcing the partition. The heap vs. stack partition is meaningful only to applications developers, and can be ignored by most users. Further complicating matters, the global array (GA) toolkit is allocated from within the MA space on distributed memory machines, while on shared-memory machines it is separate. This is because on true shared-memory machines there is no choice but to allocate GAs from within a shared-memory segment, which is managed differently by the operating system.
On distributed memory platforms, the MA region is actually the total size of stack+heap+global. All three types of memory allocation compete for the same pool of memory, with no limits except on the total available memory. This relaxation of the memory category definitions usually benefits the user, since it can allow allocation requests to succeed where a stricter memory model would cause the directive to fail. These implementation characteristics must be kept in mind when reading program output that relates to memory usage.
Standard default for memory is currently 400 MB.
This start-up directive is provided as a convenient way to include a listing of the input file in the output of a calculation. It causes the entire input file to be printed to Fortran unit six (standard output). It has no keywords, arguments, or options, and consists of the single line:
The ECHO directive is processed only once, by Process 0 when the input file is read.
Specify job title.
This top-level directive allows the user to identify a job or series of jobs that use a particular database. It is an optional directive, and if omitted, the character string containing the input title will be empty. Multiple TITLE directives may appear in the input file (e.g., the water example file) in which case a task will use the one most recently specified. The format for the directive is as follows:
TITLE <string title>
The character string <title> is assigned to the contents of the string following the TITLE directive. If the string contains white space, it must be surrounded by double quotes. For example,
title "This is the title of my NWChem job"
The title is stored in the database and will be used in all subsequent tasks/jobs until redefined in the input.
The PRINT and NOPRINT directives allow the user to control how much output NWChem generates. These two directives are special in that the compound directives for all modules are supposed to recognize them. Each module can control both the overall print level (general verbosity) and the printing of individual items which are identified by name (see below). The standard form of the PRINT directive is as follows:
PRINT [(none || low || medium || high || debug) default medium] [<string list_of_names ... >] NOPRINT <string list_of_names ... >
The default print level is medium.
Every output that is printed by NWChem has a print threshold associated with it. If this threshold is equal to or lower than the print level requested by the user, then the output is generated. For example, the threshold for printing the SCF energy at convergence is low. This means that if the user-specified print level on the PRINT directive is low, medium, high, or debug, then the SCF energy will be printed at convergence.
The overall print level specified using the PRINT directive is a convenient tool for controlling the verbosity of NWChem. Setting the print level to high might be helpful in diagnosing convergence problems. The print level of debug might also be of use in evaluating problem cases, but the user should be aware that this can generate a huge amount of output. Setting the print level to low might be the preferable choice for geometry optimizations that will perform many steps which are in themselves of little interest to the user.
In addition, it is possible to enable the printing of specific items by naming them in the PRINT directive in the <list_of_names>. Items identified in this way will be printed, regardless of the overall print level specified. Similarly, the NOPRINT directive can be used to suppress the printing of specific items by naming them in its <list_of_names>. These items will not be printed, regardless of the overall print level, or the specific print level of the individual items.
The list of items that can be printed for each module is documented as part of the input instructions for that module. The items recognized by the top level of the code, and their thresholds, are:
|'Print Level;'
|"total time";
|Print cpu and wall time at job end
|"task time"
|Print cpu and wall time for each task
|Print names of RTDB entries
|Print name and values of RTDB entries
|"ga summary"
|Summarize GA allocations at job end
|"ga stats"
|Print GA usage statistics at job end
|"ma summary"
|Summarize MA allocations at job end
|"ma stats"
|Print MA usage statistics at job end
|Print version number of all compiled routines
|Print TCGMSG debug information
Top Level Print Control Specifications
The following example shows how a PRINT directive for the top level process can be used to limit printout to only essential information. The directive is
print none "ma stats" rtdb
This directive instructs the NWChem main program to print nothing, except for the memory usage statistics (ma stats) and the names of all items stored in the database at the end of the job.
The print level within a module is inherited from the calling layer. For instance, by specifying the print to be low within the MP2 module will cause the SCF, CPHF and gradient modules when invoked from the MP2 to default to low print. Explicit user input of print thresholds overrides the inherited value.
This top-level directive allows the user to enter data directly into the run-time database. The format of the directive is as follows:
SET <string name> [<string type default automatic>] <type data>
The entry for variable <name> is the name of data to be entered into the database. This must be specified; there is no default. The variable <type>, which is optional, allows the user to define a string specifying the type of data in the array <name>. The data type can be explicitly specified as integer, real, double, logical, or string. If no entry for <type> is specified on the directive, its value is inferred from the data type of the first datum. In such a case, floating-point data entered using this directive must include either an exponent or a decimal point, to ensure that the correct default type will be inferred. The correct default type will be inferred for logical values if logical-true values are specified as .true., true, or t, and logical-false values are specified as .false., false, or f. One exception to the automatic detection of the data type is that the data type must be explicitly stated to input integer ranges, unless the first element in the list is an integer that is not a range. For example,
set atomid 1 3:7 21
will be interpreted as a list of integers. However,
set atomid 3:7 21
will not work since the first element will be interpreted as a string and not an integer. To work around this feature, use instead
set atomid integer 3:7 21
which says to write three through seven, as well as twenty-one.
The SET directive is useful for providing indirection by associating the name of a basis set or geometry with the standard object names (such as "ao basis" or geometry) used by NWChem. The following input file shows an example using the SET directive to direct different tasks to different geometries. The required input lines are as follows:
title "Ar dimer BSSE corrected MP2 interaction energy" geometry "Ar+Ar" Ar1 0 0 0 Ar2 0 0 2 end geometry "Ar+ghost" Ar1 0 0 0 Bq2 0 0 2 end basis Ar1 library aug-cc-pvdz Ar2 library aug-cc-pvdz Bq2 library Ar aug-cc-pvdz end set geometry "Ar+Ar" task mp2 scf; vectors atomic; end set geometry "Ar+ghost" task mp2
This input tells the code to perform MP2 energy calculations on an argon dimer in the first task, and then on the argon atom in the presence of the "ghost" basis of the other atom.
The SET directive can also be used as an indirect means of supplying input to a part of the code that does not have a separate input module (e.g., the atomic SCF). Additional examples of applications of this directive can be found in the sample input files, and its usage with basis sets and geometries. Also see database section for an example of how to store an array in the database.
Delete data in the RTDB.
This directive gives the user a way to delete simple entries from the database. The general form of the directive is as follows:
UNSET <string name>[*]
This directive cannot be used with complex objects such as geometries and basis sets. Complex objects are stored using a structured naming convention that is not matched by a simple wild card. A wild-card (*) specified at the end of the string <name> will cause all entries whose name begins with that string to be deleted. This is very useful as a way to reset modules to their default behavior, since modules typically store information in the database with names that begin with module:. For example, the SCF program can be restored to its default behavior by deleting all database entries beginning with scf:, using the directive
unset scf:*
Section -sec:fragguess- has an example using unset on a water dimer calculation.
The following example makes an entry in the database using the SET directive, and then immediately deletes it using the UNSET directive:
set mylist 1 2 3 4 unset mylist
Terminate processing.
This top-level directive provides a convenient way of verifying an input file without actually running the calculation. It consists of the single line,
As soon as this directive is encountered, all processing ceases and the calculation terminates with an error condition.
The TASK directive is used to tell the code what to do. The input directives are parsed sequentially until a TASK directive is encountered, as described in Input File Structure. At that point, the calculation or operation specified in the TASK directive is performed. When that task is completed, the code looks for additional input to process until the next TASK directive is encountered, which is then executed. This process continues to the end of the input file. NWChem expects the last directive before the end-of-file to be a TASK directive. If it is not, a warning message is printed. Since the database is persistent, multiple tasks within one job behave exactly the same as multiple restart jobs with the same sequence of input.
There are four main forms of the the TASK directive. The most common form is used to tell the code at what level of theory to perform an electronic structure calculation, and which specific calculations to perform. The second form is used to specify tasks that do not involve electronic structure calculations or tasks that have not been fully implemented at all theory levels in NWChem, such as simple property evaluations. The third form is used to execute UNIX commands on machines having a Bourne shell. The fourth form is specific to combined quantum-mechanics and molecular-mechanics (QM/MM) calculations.
By default, the program terminates when a task does not complete successfully. The keyword ignore can be used to prevent this termination, and is recognized by all forms of the TASK directive. When a TASK directive includes the keyword ignore, a warning message is printed if the task fails, and code execution continues with the next task. An example of this feature is given in the sample input file.
The input options, keywords, and defaults for each of these four forms for the TASK directive are discussed in the following sections.
TASK Directive for Electronic Structure
This is the most commonly used version of the TASK directive, and it has the following form:
TASK <string theory> [<string operation default energy>] [ignore]
The string <theory> specifies the level of theory to be used in the calculations for this task. NWChem currently supports ten different options. These are listed below, with the corresponding entry for the variable <theory>:
- scf - Hartree-Fock
- dft - Density functional theory for molecules
- sodft - Spin-Orbit Density functional theory
- mp2 - MP2 using a semi-direct algorithm
- direct_mp2 - MP2 using a full-direct algorithm
- rimp2 - MP2 using the RI approximation
- ccsd - Coupled-cluster single and double excitations
- ccsd(t) - Coupled-cluster linearized triples approximation
- ccsd+t(ccsd)# - Fourth order triples contribution
- mcscf - Multiconfiguration SCF
- selci - Selected configuration interaction with perturbation correction
- md - Classical molecular dynamics simulation
- pspw - Pseudopotential plane-wave density functional theory for molecules and insulating solids using NWPW
- band - Pseudopotential plane-wave density functional theory for solids using NWPW
- tce - Tensor Contraction Engine
The string <operation> specifies the calculation that will be performed in the task. The default operation is a single point energy evaluation. The following list gives the selection of operations currently available in NWChem:
- energy - Evaluate the single point energy.
- gradient - Evaluate the derivative of the energy with respect to nuclear coordinates.
- optimize - Minimize the energy by varying the molecular structure. By default, this geometry optimization is presently driven by the Driver module, but the Stepper module may also be used.
- saddle - Conduct a search for a transition state (or saddle point) using either Driver module (the default) or Stepper.
- hessian - Compute second derivatives. See hessian section for analytic hessians.
- frequencies or freq - Compute second derivatives and print out an analysis of molecular vibrations. See vibration section for controls for vibration calculations.
- vscf - Compute anharmonic contributions to the vibrational modes. See the vibrational SCF section for options.
- property - Calculate the properties for the wave function.
- dynamics - Perform classical molecular dynamics.
- thermodynamics - Perform multi-configuration thermo-dynamic integration using classical MD
NOTE: See PSPW Tasks for the complete list of operations that accompany the NWPW module.
The user should be aware that some of these operations (gradient, optimize, dynamics, thermodynamics) require computation of derivatives of the energy with respect to the molecular coordinates. If analytical derivatives are not available (Capabilities), they must be computed numerically, which can be very computationally intensive.
Here are some examples of the TASK directive, to illustrate the input needed to specify particular calculations with the code. To perform a single point energy evaluation using any level of theory, the directive is very simple, since the energy evaluation is the default for the string operation. For an SCF energy calculation, the input line is simply
task scf
Equivalently, the operation can be specified explicitly, using the directive
task scf energy
Similarly, to perform a geometry optimization using density functional theory, the TASK directive is
task dft optimize
The optional keyword ignore can be used to allow execution to continue even if the task fails, as discussed above. An example with the keyword ignore can be found in the DFT example.
TASK Directive for Special Operations
This form of the TASK directive is used in instances where the task to be performed does not fit the model of the previous version (such as execution of a Python program), or if the operation has not yet been implemented in a fashion that applies to a wide range of theories (e.g., property evaluation). Instead of requiring theory and operation as input, the directive needs only a string identifying the task. The form of the directive in such cases is as follows:
TASK <string task> [ignore]
The supported tasks that can be accessed with this form of the TASK directive are listed below, with the corresponding entries for string variable <task>.
- python - Execute a Python program.
- rtdbprint - Print the contents of the database.
- cphf - Invoke the CPHF module.
- property - Perform miscellaneous property calculations.
- dplot - Execute a DPLOT run.
This directive also recognizes the keyword ignore, which allows execution to continue after a task has failed.
TASK Directive for Bourne Shell
This form of the TASK directive is supported only on machines with a fully UNIX-style operating system. This directive causes specified processes to be executed using the Bourne shell. This form of the task directive is:
TASK shell [(<integer-range process = 0>||all)] <string command>
The keyword shell is required for this directive. It specifies that the given command will be executed in the Bourne shell. The user can also specify which process(es) will execute this command by entering values for process on the directive. The default is for only process zero to execute the command. A range of processes may be specified, using Fortran triplet notation. Alternatively, all processes can be specified simply by entering the keyword all. The input entered for command must form a single string, and must consist of valid UNIX command(s). If the string includes white space, it must be enclosed in double quotes.
For example, the TASK directive to tell process zero to copy the molecular orbitals file to a backup location /piofs/save can be input as follows:
task shell "cp *.movecs /piofs/save"
The TASK directive to tell all processes to list the contents of their /scratch directories is as follows:
task shell all "ls -l /scratch"
The TASK directive to tell processes 0 to 10 to remove the contents of the current directory is as follows:
task shell 0:10:1 "/bin/rm -f *"
Note that NWChem's ability to quote special input characters is very limited when compared with that of the Bourne shell. To execute all but the simplest UNIX commands, it is usually much easier to put the shell script in a file and execute the file from within NWChem.
TASK Directive for QM/MM simulations
This is very similar to the most commonly used version of the TASK directive, and it has the following form:
TASK QMMM <string theory> [<string operation default energy>] [ignore]
The string <theory> specifies the QM theory to be used in the QM/MM simulation. If theory is "md" this is not a QM/MM simulation and will result in an appropriate error. The level of theory may be any QM method that can compute gradients but those algorithms in NWChem that do not support analytic gradients should be avoided (see Functionality).
The string <operation> is used to specify the calculation that will be performed in the QM/MM task. The default operation is a single point energy evaluation. The following list gives the selection of operations currently available in the NWChem QM/MM module;
- energy - single point energy evaluation
- optimize - minimize the energy by variation of the molecular structure.
- dynamics - molecular dynamics using nwARGOS
Here are some examples of the TASK directive for QM/MM simulations. To perform a single point energy of a QM/MM system using any QM level of theory, the directive is very simple. As with the general task directive, the QM/MM energy evaluation is the default. For a DFT energy calculation the task directive input is,
task qmmm dft
or completely as
task qmmm dft energy
To do a molecular dynamics simulation of a QM/MM system using the SCF level of theory the task directive input would be
task qmmm scf dynamics
The optional keyword ignore can be used to allow execution to continue even if the task fails, as discussed above.
TASK Directive for BSSE calculations
NWChem computes the basis set superposition error (BSSE) when two or more fragments are interacting by using the counterpoise method. This directive is performed if the BSSE section is present. Single point energies, energy gradients, geometry optimizations, Hessians and frequencies, at the level of theory that allows these tasks, can be obtained with the BSSE correction. The input options for the BSSE section are:
BSSE MON <string monomer name> <integer natoms> [INPUT [<string input>]] [INPUT_WGHOST[<string input>]] [CHARGE [<real charge>]] [ MULT <integer mult>] [OFF] [ON] END
MON defines the monomer's name and its atoms; <string monomer name> defines the name of the monomer, <integer atoms> is the list of atoms corresponding to the monomer (where such a list is relative to the initial geometry). This information is needed for each monomer. With the tag INPUT the user can modify any calculation attributes for each monomer without ghost. For example, the iterations number and the grid can be changed in a DFT calculation (see the example of the interaction between Zn2 + and water). INPUT_WGHOST is the same than INPUT but for the monomer with ghost. The input changes will be applied within this and for the following calculations, you should be cautious reverting the changes for the next monomers. CHARGE assigns a charge to a monomer and it must be consistent with the total charge in the whole system (see Section -sec:charge-). The options OFF and ON turns off and on any BSSE calculation.
The energy evaluation involves 1 + 2N calculations, i.e. one for the supermolecule and two for the N monomers. [S. Simon, M. Duran, J. J. Dannenberg, J. Chem. Phys., 105, 11024 (1996)] NWChem stores the vector files for each calculation (<string monomer name>.bsse.movecs), and one hessian file (<string monomer name>.bsse.hess). The code does not assign automatically the basis set for the ghost atoms, you must assign the corresponding bqX for each element, instead.
The dimer (FH)2
title dimer start dimer geometry units angstrom symmetry c1 F 1.47189 2.47463 -0.00000 H 1.47206 3.29987 0.00000 F 1.46367 -0.45168 0.00000 H 1.45804 0.37497 -0.00000 end basis "ao basis" F library 6-31G H library 6-31G bqF library F 6-31G bqH library H 6-31G end dft; xc slater 1.0 vwn_5 1.0; direct; end bsse mon first 1 2 mon second 3 4 end task dft energy
Changing maxiter for a specific monomer: Zn2 + (H2O)
title znwater start znwater echo geometry noautoz units angstrom symmetry c1 Zn -1.89334 -0.72741 -0.00000 O -0.20798 0.25012 0.00000 H -0.14200 1.24982 -0.00000 H 0.69236 -0.18874 -0.00000 end basis "ao basis" O library 6-31G Zn library 6-31G H library 6-31G bqO library O 6-31G bqZn library Zn 6-31G bqH library H 6-31G end charge 2 scf; direct; end mp2; end bsse mon metal 1 charge 2 input_wghost "scf\; maxiter 200\; end" mon water 2 3 4 end task mp2 optimize
The ECCE_PRINT directive allows the user to print out a file, usually called ecce.out, that will allow the calculation and its results to be imported into Ecce (see http://ecce.pnl.gov).
ECCE_PRINT <string name>
The entry for variable <name> is the name of the file that will contain the Ecce import information and should include the full path to the directory where you want that file. For example
ecce_print /home/user/job/ecce.out
If the full path is not given and only the file name is given, the file will be located in whatever directory the job is started in. For example, if the line
ecce_print ecce.out
is in the input file, the file could end up in the scratch directory if the user is using a batch script that copies the input file to a local scratch directory and then launches NWChem from there. If the system then automatically removes files in the scratch space at the end of the job, the ecce.out file will be lost. So, the best practice is to include the full path name for the file.


text:
The final HMMER3 beta test release is available for download as a tarball. It includes precompiled binaries for Intel/Linux systems, both 64-bit (x86_84) and 32-bit (ia32) platforms, and you may just copy these into some directory in your $PATH if you like. If the precompiled versions don't work for you, you can always compile your own version from the source.
The main additions in 3.0b3 are parallelizations and even more speed. It now includes support for multicores (POSIX multithreading) and support for clusters (MPI). For the first time, we're seeing some searches peek above NCBI BLAST search speed. Yes, you read that right, profile HMM speeds have started to exceed BLAST speed. And we're far from done.
The release notes for 3.0b3 follow:
HMMER 3.0b3 release notes : HMMER3 beta test, release 3
SRE, Fri Nov 13 16:22:28 2009
With this release, HMMER 3.0 is nearly complete, as far our design goals for the first public release. This release, 3.0b3, is likely to be the final beta test release. The next release is planned for mid-December 2009, and is likely to be the 3.0 public release.
The main thing that is missing now is good documentation, and two manuscripts we're planning for describing HMMER3 technology. We expect to focus on documentation and additional testing for the next few weeks. We may also add more support for different input formats, especially multiple alignment formats. We may also add a binary sequence database format and an executable to produce that format (akin to BLAST's xdformat or formatdb); input from disk is now our most important bottleneck in speed, not computational time.
We welcome Michael Farrar and Travis Wheeler to the HMMER3 development team. This release includes their first code contributions. We also welcome Bjarne Knudsen (CLCbio, Aarhus, Denmark) as a collaborator on the HMMER project. We expect to begin including Bjarne's contributions in the next release.
Most important new features:
- Multithreaded parallelization for multicore machines.
The four search programs now support multicore parallelization. By default, they will use all available cores on your machine. You can control the number of cores each HMMER process will use with the –cpu command line option or the HMMER_NCPU environment variable. Accordingly, you should observe about a 2x or 4x speedup on dual-core or quad-core machines, relative to previous releases. Even with a single CPU (–cpu 1), HMMER will devote a separate execution thread to database input, resulting in significant speedup over serial execution.
To turn off POSIX threads support, recompile from source after giving the '–disable-threads' flag to ./configure.
- MPI parallelization for clusters.
The four search programs and hmmbuild now also support MPI parallelization on clusters that have MPI installed. In binaries compiled for MPI support, an "–mpi" option is available for running a master/worker parallelization model under MPI.
To use MPI support, you need to compile your own HMMER binaries from source. We do not put MPI support in our precompiled binaries, because we can't be sure your have an MPI library (like OpenMPI) installed. To enable MPI support, the '–enable-mpi' flag to when you ./configure.
- Support for PowerPC and other processors.
Previously, HMMER3 only supported x86-compatible processors that support SSE2 vector instructions. This includes Intel processors Pentium 4 on, and AMD processors from K8 (Athlon 64) on; we believe this includes almost all Intel processors since 2000 and AMD processors since 2003.
HMMER now also supports PowerPC processors that support Altivec/VMX vector instructions. This includes Motorola G4, IBM G5, and IBM Power6 processors, which we believe includes almost all PowerPC-based desktop systems since 1999 and servers since 2007.
Your processor type is automatically detected at configuration time. You will see it choose one of two vector implementations: "impl_sse" or "impl_vmx". If you want (or if it fails to detect your machine properly) you can force the choice with './configure –enable-sse' or './configure –enable-vmx'.
If you have a processor that our vector implementations don't currently support, the ./configure will detect this and set you up with the "dummy" implementation, impl_dummy. The dummy implementation should work on anything (that supports POSIX/ANSI C99, anyway). The dummy implementation is very portable, but because it does not use a vector instruction set at all, it is very slow. The intent of the dummy implementation is to make sure that you can reproduce HMMER3 results almost anywhere, even if you have to wait for them.
- A change in the logic of how reporting thresholds are applied.
3.0b2 had a deliberate "design feature" in how it applies reporting thresholds including Pfam GA/TC/NC bit score thresholds that has disturbed many people. If a sequence passed the per-sequence score threshold, then at least one domain (the best-scoring) was always reported in the per-domain output, regardless of whether the domain had passed the per-domain threshold GA2 or not. The idea was that we didn't want you complaining that a sequence was reported in the per-sequence output, so where was it in the domain output? Trouble was, anyone trying to apply reporting cutoffs strictly (Pfam GA cutoffs, for example) gets peeved, because domains appear in the per-domain output that have not met the domain threshold.
3.0b3 changes this behavior. Reporting thresholds are now applied strictly.
- A change in the logic of how filter thresholds are applied.
3.0b2 had a deliberate "design feature" in how it applied thresholds to the fast heuristic filters in its sequence processing pipeline. The MSV, Viterbi, and Forward filter scores are required to pass certain P-value thresholds (0.022, 0.001, and 1e-5 by default, respectively) before a sequence is subjected to full Forward/Backward computations. On a small number of target comparisons, the filter thresholds (especially the 1e-5 Forward filter threshold) could become more stringent than the reporting thresholds, and a sequence that passes the reporting thresholds wouldn't be reported, because it failed at the filters. For example, a sequence with a Forward score with a P-value of 0.0001 would have a reportable E-value of 0.01 if you only search 100 sequences, but 0.0001 fails the Forward score filter threshold. Therefore 3.0b2 did an "OR test": it also allows a sequence through the filters if its score and E-value pass the reporting thresholds. But this has all kinds of weird side effects with sequences winking counterintuitively in and out of reported output. One is that a sequence might pass the filters in a small database, but not in a large one. Also, because E-value estimates during a search have to be lower-bound estimates based on the number of sequences seen so far (it doesn't know the total number of sequences in a FASTA file 'til the search is done), a sequence could wink in and out of output depending on the order of sequences in the sequence database.
The OR test is now removed. Comparisons must strictly pass specified P-value thresholds at each of the three filters. Search outputs are more strictly reproducible as a result.
If you compare to 3.0b2 outputs, you may notice fewer hits being reported with marginal to poor E-values, because 3.0b3 is failing some of these sequences at the filter steps.
- A change in the tabular output formats.
Both tabular output formats (–tblout and –domtblout) now include columns giving the accessions for the query and the target, in addition to their names. If an accession isn't available, a "-" (dash) appears in the accession column.
Small new features:
- The programs can read and write aligned FASTA ("afa") format. They cannot autodetect it, though. To read a multiple file in afa format, use "–informat afa" for programs that accept the –informat option.
- hmmalign now has an –allcol option, which forces it to output an aligned column for every consensus position, even if a consensus column contains all gap characters. This can be useful when you're trying to keep track of some sort of stable labeling/numbering on aligned consensus columns for a model.
- The search programs now have a –noali option, to suppress the voluminous alignment output. (Here, in big production work, we commonly send the main output to /dev/null, and use –tblout and –domtblout to capture the results in easily parsed space-delimited tabular form.)
- The search programs now have an –acc option, which requests that accessions be displayed instead of names for queries and targets, whenever an accession is known. For queries or targets lacking accessions, the name is displayed as a fallback. Because this can result in a mix of accessions and names, you should probably make sure that either all your queries/targets have accessions before you use –acc.
- In output files, the section header that read: Domain and alignment annotation for each sequence: now reads Domain annotation for each sequence (and alignments): and with the new –noali option, the " (and alignments)" phrase is omitted. If you had a parser keying off this line, watch out.
- The installation process from source code now supports using separate build directories, using the GNU-standard VPATH mechanism. This allows you to maintain separate builds for different processors or with different configuration/compilation options. All you have to do is run the configure script from the directory you want to be the root of the build directory. For example:
% mkdir my-hmmer-build
% cd my-hmmer-build
% /path/to/hmmer/configure
% make
- Sorting of top hits lists (both per-sequence and per-domain) now resolves ties in a consistent and reproducible fashion, by sorting on names, even in threaded and MPI parallel searches. This may produce small differences in order of hits seen in outputs compared to earlier H3 releases.
- The test suites have expanded modestly.
All reported bugs have been fixed:
- #h68 hmmalign fails on some seqs: Decoding ERANGE error
- #h67 H2 models produced by H2 hmmconvert aren't readable
- #h66 hmmscan output of HMM names/descriptions corrupted
- #h65 hmmpress -f corrupts HMM database instead of overwriting it
- #h64 traces containing X (fragments) are misaligned
- #h63 stotrace unit test may fail on i686 platforms
- #h62 hmmscan segfaults on sequences containing * characters
- #h61 hmmscan –cut_{ga,nc,tc} fails to impose correct thresholds
- #h60 hmmbuild –mpi fails to record GA,TC,NC thresholds
- #h59 seq descriptions containing '%' cause segfault
- #h58 hmmscan tabular domain output reverses target, query lengths
- #h57 jackhmmer fails: "backconverted subseq didn't end at expected length"
Some unreported bugs are fixed, including:
- hmmsim was using a weak random number generator; could cycle/repeat
- a bug in calculating checksums for multiple alignments is fixed.
(HMMs built with 3.0b2 or earlier will have different alignment checksums recorded in their HMM files than 3.0b3 calculates. This means that hmmalign –mapali will fail, if you try to use 3.0b3 hmmalign –mapali with models constructed with versions prior to 3.0b3.)


text:
Making Devices Smarter & Sleeker
Connecting Anything to Everything
Enabling Intelligent Automation
Making Innovation Easier
FPGA, CPLD & System Management Optimized for Low Power & Small Size
World's Smallest FPGAs
MIPI Video Bridging FPGA
Bridging & Expansion FPGAs
Power & Thermal Management
Connectivity & Acceleration
All You Need to Complete a Design
Complete Design Tools, Easy to Use
HDMI Devices to Enhance Your HD Products
Help Choosing the Right Products
Need Help? We're Here to Assist You
Find the Right FPGA Software & IP Licenses
Key Reference Materials
Outside Resources to Help Get the Job Done
Browse Our Legacy Products
Direct, Rep, & Distribution
Buy Lattice Products via the Web
Buy End-of-Life Lattice Products
Who is Lattice?
Information for Investors & Analysts
What is Lattice Doing?
Is Lattice a Good Fit for You?
Learn more
Your browser does not support video playback.


text:
Posted April 3, 2020 by Michelle in / 0 Comments
Want more awesome posts like this? Subscribe to my blog via email!
Save my name, email, and website in this browser for the next time I comment.
Notify me of followup comments via e-mail. You can also subscribe without commenting.
This site uses Akismet to reduce spam. Learn how your comment data is processed.


text:
Deformity correction with the Taylor Spatial Frame after growth arrest of the distal radius
Search Medline for
|October 18, 2011
Questionnaire: The Taylor Spatial Frame (TSF) is a hexapod based external ring fixator, which is widely used to perform six-axis deformity corrections of the lower limb. TSF-planning is web based (www.spatialframe.com) but its use is only available for lower extremities. The purpose of this study was to apply the TSF to the upper extremities to correct pseudo-Madelung deformities.
Methods: Defining the nomenclature - To correct bony deformities with the TSF, one must determine the deformity parameters, the frame parameters, and mounting parameters for the web based planning program. The six deformity parameters and the four mounting parameters use the anatomic nomenclature for the lower extremities. To use the TSF on the forearm, one must transfer the nomenclature of the deformity parameters and the mounting parameters to the nomenclature of the forearm With the transferred nomenclature, one can correct forearm deformities with the correction mode Long Bone of the planning program for the lower limb.
Patients - Two boys (Patient 1, 13 years, Patient 2, 14 years old) and two girls (Patient 3, 8 years, Patient 4, 7 years) were seen in our clinic with progressive pseudo-Madelung deformities after an epiphysial fracture of the distal radius at age 12 in the boys and 6 in the girls. Skeletal maturity (RUS, TW3 method) was equivalent to the patient's age.
Results and Conclusions: In the two patients, the multiplanar deformitiy of the distal radius could be corrected anatomically with the TSF. There were no frame changes or frame modifications necessary for deformity correction. Patient 2 was slightly overcorrected because of some growth in the distal ulnar growth plate. During the distraction, each patient had two low-dose CT scans for better visualization of the radiocarpal and radioulnar joint. The web-based planning program was adjusted twice until total deformity correction was achieved. No further immobilization after frame removal was required. The one-year follow-up showed an anatomic aligned forearm/hand relation with increased pronation and supination compared to the preoperative range of motion in all patients. The wrist and especially the DRUJ were stable and reduced at the one-year follow-up examination. The patients did not complain about any pain or functional deficits in the hand.
In conclusion, the power of the TSF with the ability to move two fragments precisely can be transferred to the forearm. This allows for the correction of multiplanar radial deformities simultaneously without the need for frame modifications of rotational and translational deformities, as is necessary with the standard Ilizarov system.


text:
This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
OWASP Newsletter 9
Sent to owasp-all mailing list on ?? May 2007
- 1 OWASP Newsletter #9 (10-June-2007)
- 2 Featured Item: OWASP Top Ten final 2007 version !
- 3 Featured Item: SpoC2007 Selections Made !
- 4 Featured Item: 6th OWASP AppSec Conference in Italy May 15-17 was a great success
- 5 Featured Item: Planning for 7th OWASP AppSec Conference in San Jose, CA in Oct. 2007 underway.
- 6 Featured Item: OWASP on the Move!
- 7 Featured (non-OWASP) Project: Security Through Scrutiny: Java Open Review Project
- 8 Latest additions to the WIKI
- 9 OWASP references in the Media
OWASP Newsletter #9 (10-June-2007)
Welcome to the 9th OWASP Newsletter, covering:
- Final OWASP Top 10 v2007
- SpoC2007 Selections
- AppSec EU Conference in Italy
- The next Conference in San Jose, CA
- OWASP on the Move!
- (non-OWASP) Project: Java Open Review Project
And pointers to the latest changes online.
If you have any content to add to the next edition, feel free to add it directly to its WIKI page (OWASP Newsletter 10).
PS: if all you readers regularly add an item to the Application Security News section on http://www.owasp.org/index.php/Application_Security_News we most certainly become THE central point for the latest AppSec news (just an idea). We could then create a seperate news feed for your favorite aggregator.
Sebastien Deleersnyder
Belgium Chapter Leader
Featured Item: OWASP Top Ten final 2007 version !
Thanks to the hard work of Andrew and all other contributors and reviewers we are proud to present you the 2007 version of the OWASP Top 10. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws.
Featured Item: SpoC2007 Selections Made !
OWASP is funding over 25 new application security projects this Spring with over $120,000. There are a variety of tools, documents, and other projects in the works. These projects are well underway and are targeted to be complete by the end of July. Congratulations to all the participants - everyone is looking forward to your work!
Featured Item: 6th OWASP AppSec Conference in Italy May 15-17 was a great success
The 6th OWASP AppSec Conference was held May 15-17 in Milan, Italy. Microsoft presented on "The Benefits of the SDL initiative to Microsoft and its Customers" and there were expert talks on Web Services Security, Securing AJAX, the Microsoft Secure Development Lifecycle, all the new OWASP projects, and much more.
You can read all the details and then access all the presentations online on the agenda page.
Featured Item: Planning for 7th OWASP AppSec Conference in San Jose, CA in Oct. 2007 underway.
We are now starting to plan the details for the 7th OWASP AppSec Conference which will be held in Oct 2007 in the San Jose, CA area. This conference will be our biggest ever with two full days of tutorials, two days for the conference (including a new 3rd track on Web Services Security), and a vendor booth area for the first time. Please check back for additional details which should be available soon.
Featured Item: OWASP on the Move!
Following discussions during the conference in Italy we had the idea of supporting OWASP presenters to spread the word at local chapter meetings and security events.
We have set up a first trial in Belgium where Ivan Ristic and Dinis will be doing presentations June 22nd. F5 Networks has locally sponsored their trip with € 1000. Program on http://www.owasp.org/index.php/Belgium. A first stub is set up at http://www.owasp.org/index.php/OWASP_on_the_Move (WikiMedia Kung-Fu Masters are invited to make the page look better :-)
Helsinki is already looking for OWASP speakers on SDLC, so if you are interested or know someone: contact Mikka!
Featured (non-OWASP) Project: Security Through Scrutiny: Java Open Review Project
A joint project from the Findbugs group and Fortify Software is examining open source components for security and quality defects. The project, accessible at http://opensource.fortifysoftware.com, allows participants to:
- submit projects to be scanned with Findbugs and Fortify Source Code Analysis suite
- help review potential defects through the online code review interface
- keep track of project defects as they are uncovered and fixed by the open source community
- receive tips on performing code reviews for security defects
The project is open to all Java open source projects and any person that wants to contribute, either through code reviews, project submissions, or project feedback. Current projects include: Tomcat, Jforums, Azureus, Nuxeo, Spring, Struts, select OWASP projects, and more!
People are encouraged to visit the site: http://opensource.fortifysoftware.com for more details or stop by the Fortify/Findbugs demo booth at JavaOne 2007. Project owners that are interested in being featured can email: openaudit <at> fortifysoftware <dot> com
Latest additions to the WIKI
Updated Chapter Pages
- Greece
- Ottawa
- Cleveland
- Chicago
- Sacramento
- Bangalore
- 2nd OWASP IL mini conference
- Vancouver
- Turkey
- Boston
- Denver
- SoCal
- Toronto
- Kansas City
- New York
- New Jersey
- NYNJMetro
- Helsinki
- Belgium
- Luxemburg
- Houston
- Switzerland
- Phoenix
- Virginia (Northern Virginia)
- Taiwan
- Long Island
- Austin
- Italy
- Minneapolis St Paul
Other pages
- Session Management
- Guide to Authorization
- Ajax and Other "Rich" Interface Technologies
- Web Services
- Buffer Overflows
- Category:OWASP Orizon Project
- DN BOFinder
- Category:OWASP .NET Project
- Category:OWASP Guide Project
- Category:OWASP Top Ten Project
- Category:OWASP Chapter
- Scripting in WebScarab
- Handling E-Commerce Payments
- Assume attackers have source code
- Member Offers
- Data Validation
- OWASP Stinger Version 2
- Category:OWASP Tools Project
- Java Server Faces
- Cross Site Scripting
- Category:OWASP Testing Project
- OWASP Education Presentation
- Getting Started
- Java Security Resources
- Category:OWASP WebGoat Project
- How to value the real risk
- Failure to verify authorization
- Testing for XML Structural
- Man-in-the-middle attack
- Preventing LDAP Injection in Java
- Path Traversal
- Script in IMG tags
- Server-Side Includes (SSI) Injection
- 6th OWASP AppSec Conference - Italy 2007/Agenda
- OWASP News
- Membership
- OWASP Community 2006
- Category:OWASP Live CD Project
- Phoenix/Tools
- Phoenix/ToolsProfile
- JAAS Tomcat Login Module
- Category:OWASP PHP AntiXSS Library Project
- Using password systems
- XPATH Injection
- OWASP Application Security FAQ
New pages
A selection of new pages:
- OWASP on the Move
- Universal PDF XSS
- Webscarab XSS-CRLF plugin
- Escaping the phishing net
- Struts
- Scripting in WebScarab
- Category:OWASP Certification Criteria Project
- Category:OWASP Application Security Requirements Project
- Category:OWASP Communications Project
- OWASP Band One of the highlights at the 6th OWASP AppSec Conference in Milan was probably the first concert of the "OWASP Band" which was leaded by Dinis Cruz.
- Anatomy of 2 Web Applications Testing
New Documents & Presentations from chapters
For a complete list of chapter presentations see the online table of presentations.
Latest Blog entries
- OWASP, Evangelism and Ounce
- HOWTO: Bastion XSSString
- Orizon v.0.10-b25
- Bastion contest
- Switching to Java6?
- Eu conf…
OWASP Community
Chapter news:
- Three new chapters: Boulder, Calgary and Pune.
- The Belgium and Luxemburg chapter are combined into a new BeLux chapter.
- Mar 30 - NYC and New Jersey OWASP Chapter Combine: Over 500 Members combined - NY/NJ Metro
Upcoming Chapter meetings:
- June 12 (18:00hr) - NY/NJ Metro chapter meeting
- Jun 5 (18:00h) - Melbourne chapter meeting
- May 29 (9:00h) - [[email protected] Tecnologia]
- May 21 (14:00h) - 2nd OWASP Israel mini conference
- May 15 (18:00h) - Rochester chapter meeting
- May 10 (18:00h) - Belgium chapter meeting
- May 9 (18:00h) - Toronto chapter meeting
- May 8 (18:00h) - Washington DC (N. VA) chapter meeting
- May 2 (18:30h) - Boston chapter meeting
- May 1 (18:00h) - Melbourne chapter meeting
Application Security News
- Apr 21 - Concurrency and porn
- "First it was porn, now it's privacy - a technical stuff-up on reality show Big Brother's website is said to have exposed the personal details of fans who signed up for its special features. Following reports that visitors to a pirate Big Brother site were sent to a hardcore porn page, it now seems the names and phone numbers of people who registered for the official site were able to be viewed by others"
- Apr 21 - Does first Vista 0day undermine SDL?
- Ken van Wyk discusses the importance of process for producing secure software, and notes that attacks on Vista may undermine the general support for Microsoft's approach. Check out Michael Howard's talk from the last OWASP conference for a great discussion on the success of the SDL.
- Apr 19 - Why the software market is full of lemons
- Bruce Schneier finally chimes in on an [old OWASP theme] - the problem of assymetric information between software buyers and sellers. He only talks about security products, but the same problem affects all types of software. Check the [Software Facts Label which is an idea for actually doing something to change the game.
- Apr 10 - "There is no hope"
- Despite all the good stuff at OWASP, Scott Berinato is giving up. "No official announcement is forthcoming, but the Internet is broken and it can't be repaired. Oh, it's still there. You can still use it. Then again, if you went hiking and came across an old, broken-down mine shaft, you could still use that, too."
OWASP references in the Media
- Reflection on Andrew Van Der Stock
- Security Metrics
- Security concerns in the Web 2.0 world
- The ISM Community Revamp
- Guy Podjarny to Present at San Antonio OWASP
- Google AJAX Feed API Dangers
- Lock it down: Use the revised OWASP Top Ten to secure your Web applications - Part 5
- Writing Secure Code: The Root Cause of the Problem?
- Scottish Developers Security Day


text:
Pilot Study of High-Concentration Capsaicin Patches in the Treatment of Painful HIV-Associated Neuropathy
|The safety and scientific validity of this study is the responsibility of the study sponsor and investigators. Listing a study does not mean it has been evaluated by the U.S. Federal Government. Read our disclaimer for details.
|ClinicalTrials.gov Identifier: NCT00061152
Recruitment Status : Unknown
Verified September 2007 by NeurogesX.
Recruitment status was: Active, not recruiting
First Posted : May 22, 2003
Last Update Posted : September 14, 2007
- Study Details
- Tabular View
- No Results Posted
- Disclaimer
- How to Read a Study Record
|Condition or disease
|HIV Infections
|Drug: Capsaicin Dermal Patch
|Phase 2
|Study Type :
|Interventional (Clinical Trial)
|None (Open Label)
|Primary Purpose:
|Official Title:
|An Open-Label Pilot Study of High-Concentration Capsaicin Patches in the Treatment of Painful HIV-Associated Neuropathy
Choosing to participate in a study is an important personal decision. Talk with your doctor and family members or friends about deciding to join a study. To learn more about this study, you or your doctor may contact the study research staff using the contacts provided below. For general information, Learn About Clinical Studies.
|Ages Eligible for Study:
|18 Years to 75 Years (Adult, Older Adult)
|Sexes Eligible for Study:
|Accepts Healthy Volunteers:
Inclusion Criteria:
- Between 18 and 75 years of age.
- Documented evidence of HIV-1 infection.
- Painful HIV-associated neuropathy, whether resulting from HIV disease and/or antiretroviral drug exposure, with primary symptoms of pain, burning or dysesthetic discomfort in both feet for at least 2 months prior to Screening Visit.
- Diminished ankle reflexes (compared to the knee) or absent ankle reflexes,
- Distal diminution of either vibration sensation or pain or temperature sensation in the legs.
- Either no neurotoxic antiretroviral (i.e., didanosine [ddI], zalcitabine [ddC], or stavudine [d4T]) exposure for at least 8 weeks prior to Screening Visit,
- Currently on stable dose(s) of any of the neurotoxic antiretrovirals listed above for at least 8 weeks prior to Screening Visit, without a foreseeable need to change doses or medications for duration of study.
- Screening Pain Sum Score of 12 to 36.
- Intact, unbroken skin over the painful area(s) to be treated.
- If taking chronic pain medications, be on a stable (not PRN) regimen for at least 7 days prior to Treatment Visit (Day 0) and willing to maintain medications at same stable dose(s) and schedule throughout the study.
- Be willing and able to use Roxicodone® (oxycodone) oral solution, if needed, to relieve treatment-associated discomfort.
- Female subjects with child-bearing potential must have a negative urine or serum pregnancy test, to be performed at the Screening Visit.
- All subjects must be willing to use effective methods of birth control and/or refrain from participating in a conception process during the study and for 30 days following experimental drug exposure.
- Be willing and able to comply with protocol requirements for the duration of study participation. (Such requirements include, but are not limited to: completing a daily pain diary, attending all study visits, and refraining from extensive travel during study participation.)
Exclusion Criteria:
- Presence of acute, active opportunistic infection, except oral thrush; oral, genital, or rectal herpes; and Mycobacterium avium bacteremia within 2 weeks prior to Screening Visit.
- Significant pain of an etiology other than painful HIV-associated neuropathy, for example, compression-related neuropathies, e.g., spinal stenosis, or fibromyalgia or arthritis. Subjects must not have significant ongoing pain from other cause(s) that may interfere with judging HIV-associated neuropathy pain.
- Evidence of another contributing cause for peripheral neuropathy, e.g., diabetes mellitus, hereditary neuropathy, vitamin B12 deficiency (B12 level less than or equal to 200 pg/mL) or less than 3 months of B12 supplementation prior to Screening Visit, or treatment within 90 days prior to Screening Visit with any drug that may have contributed to the sensory neuropathy.
- Any implanted medical device (spinal cord stimulator, intrathecal pump or peripheral nerve stimulator) for the treatment of neuropathic pain.
- Recent use (within 21 days preceding the Treatment Visit [Day 0]) of any topically applied pain medication, such as non-steroidal anti-inflammatory drugs, menthol, methyl salicylate, local anesthetics (including Lidoderm®), steroids or capsaicin products on the painful areas.
- Treatment for acute opportunistic infections within 14 days before Treatment Visit (Day 0). Maintenance treatment of cytomegalovirus (CMV) retinitis, Mycobacterium avium bacteremia, or cryptococcal meningitis is permitted.
- Current use of any investigational drug, or Class 1 anti-arrhythmic drugs (such as tocainide and mexiletine).
- Hypersensitivity to capsaicin (i.e., chili peppers or OTC capsaicin products), local anesthetics, Roxicodone or adhesives.
- Significant ongoing or untreated abnormalities in cardiac, renal, hepatic, or pulmonary function that may interfere either with the ability to complete the study or the evaluation of adverse events.
- Currently have active malignant disease. Malignancies in remission that do not require further treatment or Kaposi's sarcoma requiring local treatment only are allowed.
- High tolerance to opioids that precludes the ability to relieve treatment-associated discomfort with Roxicodone® if needed, as judged by investigator.
- History or current problem with prescription drug, illicit substance, or alcohol abuse from self report or as judged by investigator.
To learn more about this study, you or your doctor may contact the study research staff using the contact information provided by the sponsor.
Please refer to this study by its ClinicalTrials.gov identifier (NCT number): NCT00061152
|United States, California
|NeurogesX Investigational Site
|West Hollywood, California, United States, 90069
|United States, New York
|NeurogesX Investigational Site
|New York, New York, United States, 10029
|United States, Oregon
|NeurogesX Investigational Site
|Portland, Oregon, United States, 97209
|ClinicalTrials.gov Identifier:
|Other Study ID Numbers:
|First Posted:
|May 22, 2003 Key Record Dates
|Last Update Posted:
|September 14, 2007
|Last Verified:
|September 2007
Pain Measurement
Painful HIV Neuropathy
HIV Neuropathy
Analgesics/*therapeutic use
Capsaicin/*administration & dosage/adverse effects
Peripheral Nervous System Diseases/*complications/diagnosis/*therapy
Peripheral Nervous System Diseases/drug therapy/*etiology/physiopathology
HIV Infections
Lentivirus Infections
Retroviridae Infections
RNA Virus Infections
Virus Diseases
Sexually Transmitted Diseases, Viral
Sexually Transmitted Diseases
Immunologic Deficiency Syndromes
Immune System Diseases
Neurologic Manifestations
Signs and Symptoms
Dermatologic Agents
Sensory System Agents
Peripheral Nervous System Agents
Physiological Effects of Drugs


text:
SGRate Forum
Promotion Hub
You do not have permission to access this page. This could be due to one of several reasons:
Your usergroup(Guest) does not have permission to access this page.
You are not logged in. Fill in the following form and try again.
All times are GMT+8, the time now is 2020-8-13 03:02
Clear Cookies
- Contact Us - SGRate
- Archiver - TOP
- Style
Powered by Discuz! 6.1.0 © 2001-2008 Comsenz Inc.


text:
Nano is real! And it's not just silver and sunscreen.
Sheets of carbon nanotube material 4 yards wide and 100 yards long! Two kilometer spools of carbon nanotube yarn! Mercedes adjustable tint sunroofs! Mobile phone charging shoulder bags. Powerplastic! All of these were featured at NanoDays in Boston today.
Five years ago when we visited the Materials Research Society meeting in Boston we got some jars filled with a black powder that was supposedly carbon nanotubes. Getting some of the real stuff was exciting but there was really nothing we could do with it. We didn't even want to open the jars because we were concerned about unknown effects of inhaling the powdery material. But today at NanoDays programs in Boston, visitors heard about techniques used by Nanocomp Technologies for binding the nanotubes into ultralong strands and forming then into huge sheets or twisting them into kilometer-long twine. These macroscope products have trillions and trillions of carbon nanotubes in them. The sheet material is being used on space vehicles including the Juno spacecraft, which is scheduled to be launched this August and will spend 5 years getting to Jupiter. The Juno spacecraft will benefit from the materials light weight and resistence to damage by high or low temperatures and harsh radiation. Research Frontiers demonstrated their SPD-SmartGlassTM, a suspended [nano] particle device (SPD) that can be used in architectural applications to precisely control the passage of light, glare, and heat through laminated window panes by varying the voltage to the film. SPD-SmartGlass technology will be used in the 2012 Mercedes-Benz SLK's Magic Sky Control roof. Konarka demonstated lightweight, flexible solar panels made of Konarka Power Plastic.® This is plastic thin enough that you can roll it up or attach it to outdoor gear like tents or backbacks, carports and other kinds of shade structures, and even to window panels or widow shades. Moungi Bawendi of MIT speaking today on Quantum Magic in Nanocrystals used in a nice graphic by Richard Parez that you may have seen that shows the relative abundance of different energy sources. Here is a link to the source. http://www.asrc.cestm.albany.edu/perez


text:
Daily updates - we hope this section will be small.
There are currently 1 users browsing this forum. (0 members & 1 guests)
Use this control to limit the display of threads to those newer than the specified time frame.
Allows you to choose the data by which the thread list will be sorted.
Order threads in...
Note: when sorting by date, 'descending order' will show the newest results first.
Forum Rules


text:
Polished Floor Mount 1-3/4" Dia.
Part No.: FR20100
Warranty: 1 Year
Buy Now >
Billet Aluminum Swivel Design Floor Mount with a ball and collar design, simplifies column installation by allowing up to 30° angle. Available in both 1-3/4" and 2" diameter to fit all Flaming River column styles. Polished finish. For a finishing touch, add our Floor Mount Firewall Cover
Shipping Weight: 3lbs.
Shipping Dimensions: 8" x 6" x 6"


text:
- 3 cups milk
- 2 tablespoons unsalted butter
- 1 teaspoon salt
- 1/2 teaspoon freshly ground white pepper
- 3/4 cup stone-ground white grits
- 1 cup Parmesan-Reggiano, grated
- 3 tablespoons roasted jalapeno peppers, diced
- 1 fresh Florida lobster, split and cleaned
- 1/4 cup slivered garlic
- 2 ounces extra-virgin olive oil
- 1 ounce unsalted butter
- Juice of 1 lime
- Kosher salt and freshly ground black pepper
- 1/2 cup extra-virgin olive oil
- 1/2 cup slivered garlic
- 1/2 cup peeled and diced heirloom tomatoes
- 1 pinch crushed red pepper flakes
- 12 Venus clams, washed
- 12 Florida pink shrimp, peeled and deveined
- 1 cup white wine
- 1/2 cup unsalted butter, softened
- 4 stone crab claws, knuckle meat removed, and shell removed from the claw
- Two 3-ounce lionfish fillets, cubed
- Kosher salt and freshly ground black pepper
- 1 tablespoon fresh basil chiffonade
- 1 tablespoon chopped fresh parsley
- 1 teaspoon fresh mint chiffonade
- 1 lemon, halved
For the grits:Combine the 3 cups water, the milk, 1 tablespoon of the butter, the salt and pepper in a large saucepan over medium heat. Bring the liquid to a gentle boil. Stir in the grits. Cook for 1 hour 15 minutes, stirring occasionally. The grits will stick to the bottom of the pan, so make sure not to scrape the bottom of the pan. If the grits absorb all of the water, add some hot water to thin out the grits. Remove the pan from the heat and stir in the remaining 1 tablespoon butter, the cheese and jalapeno peppers. The grits can either be served immediately or prepared in advance and reheated.
For the lobster:Rub the lobster meat with the garlic, oil and butter and sprinkle with salt and black pepper. Grill over medium-high heat, body-side down at first, until cooked three-quarters of the way through, about 6 minutes; flip and grill meat-side down, for approximately 2 additional minutes. Remove from the grill and squeeze over the lime juice.
For the cioppino:Heat the olive oil in a saucepan over medium-high heat until just about to the smoking point; quickly add the garlic, tomatoes and red pepper flakes. Saute until the garlic becomes translucent, about 30 seconds. Add the clams, cook for 2 minutes, then add the shrimp and the wine immediately after. Simmer until the shrimp and clams are halfway cooked, then add the butter, crab claws and knuckle meat and the lionfish. Cover and simmer until the fish is barely cooked through, about 5 minutes; season with salt and black pepper, and finish with the basil, parsley, mint and a spritz of fresh lemon juice.
- Reheat the grits, if needed, and place 2 cups grits into a large, deep platter. Arrange the cioppino around the grits, and garnish with the grilled lobster. Serve.
Notes:This recipe was provided by a chef, restaurant or culinary professional and may have been scaled down from a bulk recipe. The Food Network Kitchens have not it for home use and therefore cannot make any representation as to the results.
- Recipe courtesy of Executive Chef Anthony Sicignano, The Breakers, Palm Beach, Florida
Recipe Details
- Source: Emeril's Florida: Big Night Out
Similar Recipes
Smoked Buffalo With Melted Fennel, Leeks, And Hearts Of Palm Salad With Florida Orange Vinaigrette
Roasted Rack Of Lamb With Sauce Romesco
Grilled Spicy Sausage With Florida Sweet Potatoes And Peppers With Mustard Vinaigrette
Burgers With Bacon And Cheese
Big And Crispy Onion Rings
Pecan Boniato Crusted Fish With Jalapeno Cream Sauce
Fennel Seared Swordfish With Smoked Tomato Butter, Yukon Hash And Bottarga Citrus Salad
Sausage Pizza With Caramelized Onions And Peppers
Black Grouper With Sofrito And Rock Shrimp Toast


text:
Anthony Mackie is in talks to join Mark Wahlberg and Dwayne Johnson in Michael Bay's crime flick Pain and Gain. The true story is based on a 1999 Miami New Times article about two bodybuilders who got caught up in an extortion ring and a kidnapping scheme that went terribly wrong. Per Variety, "Mackie is in negotiations to play Adrian Doorbal, a big-hearted bodybuilder who works out with, Daniel Lugo (Wahlberg). Doorbal has little to show for his hard work, leading him to get involved with Lugo's scheme." The movie also stars Rob Corddry, Ed Harris, and possibly John Turturro. Filming is set to begin this spring.
Mackie is always a strong presence even though he's usually cast in supporting roles. He'll be seen later this year in Abraham Lincoln: Vampire Hunter and The Gangster Squad. He recently wrapped shooting on Forest Whitaker's voodoo thriller, Vipka.