Stats

  • Locked Locked
  • Replies 4
  • Subscribers 142
  • Views 13559
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

openResults() bug in 6.1.5?

markbeck

I'm encountering a bug in version  6.1.5.500.1

I am seeing a bug when I do the following:

  1. Run a paramRun transient simulation
  2. Issue an openResults() command to open the result set
  3. selectResults('tran)

This results in a error "results 'tran not found".

However, if I exit virtuoso and restart, I can issue the openResults and selectResults('tran) command and virtuoso is able to see the new results.

Is anyone else seeing this bug?

Mark

 

 

Parents

  • We experienced a similar situation where a file was changed on a different machine. The file was stored on an NFS mounted Network Appliance. From my machine, I could not see the changes in the file for up to one minute. We tracked this down to the settings for NFS caching which defaults to 60 seconds. If you reduce this value, you will get a performance hit for your network disk drive, so 60 seconds is recommended. If the file was updated by one process on my machine, we would see the results immediately in another process, but if it was done on another machine, the data would be cached for some amount of time before it actually made it to disk. We were able to work around this problem by adding a call to the Unix 'ls' command on the directory containing the file. Something about the 'ls' command would force the cache to flush the data and we could see results right after that. We found that certain commands would force this "flushing" of the cache, but other commands would not. Using some text editors like 'vi' would always see the results, but 'cat' would not. I hope this helps.

    Derek

Reply

  • We experienced a similar situation where a file was changed on a different machine. The file was stored on an NFS mounted Network Appliance. From my machine, I could not see the changes in the file for up to one minute. We tracked this down to the settings for NFS caching which defaults to 60 seconds. If you reduce this value, you will get a performance hit for your network disk drive, so 60 seconds is recommended. If the file was updated by one process on my machine, we would see the results immediately in another process, but if it was done on another machine, the data would be cached for some amount of time before it actually made it to disk. We were able to work around this problem by adding a call to the Unix 'ls' command on the directory containing the file. Something about the 'ls' command would force the cache to flush the data and we could see results right after that. We found that certain commands would force this "flushing" of the cache, but other commands would not. Using some text editors like 'vi' would always see the results, but 'cat' would not. I hope this helps.

    Derek

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.