I am using Abaqus and performing a simulation in a cube with some particles inside. I ran a the simulation using a Python script, for which results look fine. So I saved some images from the Visualization module showing the strain distribution in the cube. A day later, I ran the same Python script but changed one parameter (maximum displacement applied). But now, when I see the results in the Visualization module, the cube looks like a rectangular prism. So I guess there is some sort of scaling applied to the axes. Also, this scaling is applied globally. If I go to Part or Assembly or Mesh, I will see a rectangular prism instead of a cube. I don't know how this happened if my simulation is done using the script and I did not set any changes in how the results are displayed nor I did this when exporting the images.
I have tried to look for options that are related to the scaling of the axis within Abaqus without success. I also tried to open and close Abacus in case it was something particular of the simulation, but I still see the scaling in the axes. Even if I open the odb file from which I got the images that actually show the cube, now show a rectangular prism.
Something that gave me some hope is that in the visualization "Common Plot Option", in the tab Other, in the tab Scaling, there is an uncheck box with the option "Scale coordinates". If I check the box ans set all coordinates to 1, there are no changes. If I know what the scaling factor is, I could just set the sclaing to cancel out that scaling factor. But again I don't know how it was applied.
UPDATE: I think the issue solved by itself. I have been working remotely and connecting to a Windows machie with Abaqus via the Microsoft Remote Desktop (from a Mac mini). It seems the issue appears when I use Abaqus from the remote desktop. After closing Abaqus in that Windows machine, then using it in a second Windows machine, then back again in the first Windows machine now I see the cube as a cube. I guess the cause is the remote desktop because some software behaves differently and the visualization software Paraview just won't open.
UPDATE 2: I confirmed the issue indeed happens when connecting remotely with Microsoft Remote Desktop from my Mac computer. The issue happens even when using a Python script for generating the figures to avoid opening the user interface. When running the script directly on the computer figures are fine (i.e., the cube looks like a cube). Not sure if when connecting remotely with Microsoft Remote Desktop from a Windows computer the issue will be present.
Related
Host machine: Debian 10 running NoMachine 7.2.3
Settings:
Specified H264
User Hardware Encoding enabled
Use Specific Frame Rate enabled (60FPS)
Use Acceleration enabled
Client: Windows 10 running NoMachine 7.2.3
Both machines have monitors attached.
Using NX protocol for connection.
FullScreen / Scale to Window / Desktop is currently 2560x1440 (reduced from native while testing this issue)
Specific issue:
I do a ton of work in the terminal and when viewing desktop via nomachine, the terminal caret is randomly not visible. The same issue is less noticeable with right click menus and other areas of "visual updates in small screen space." If this were another remote desktop vendor I would try to find the "don't update just regions" setting to force the entire display to update regularly, but I can't find similar settings for nomachine. I have a dedicated gigabit connection between the two machines with no other traffic on that line, so bandwidth is not an issue.
To recreate:
I disabled caret blink (using universal access / accessibility settings) so the caret is a solid block in terminal / vi. If I edit a text file in vi and move up and down, the caret will only update visually every other line or so (verified on the physical screen it is moving correctly). Same if I highlight or insert, etc. You inevitably miss a character or so or lose your place).
I have tried changing speed vs quality slider, resolutions, swapping from h264 to VP8, etc.
I have disabled:
multi-pass display encoding
frame buffering on decoding
client side image post-processing
Nothing seems to change this specific issue. Yes I can make dragging a quarter-screen-sized terminal window smoother, but that doesn't help me follow the caret in vi/vim. Both machines are nicely spec'd (client has 16G / RTX2080, server has 32G / GTX1080)
Is there a way to get nomachine to update all the screen all the time, or at least better refresh small areas like a terminal caret?
(OP): Based on a night of troubleshooting, the issue seemed to be either:
An issue with the Debian install of the nvidia drivers
The server machine is a laptop with a broken main screen (but with an HDMI external monitor plugged in). The Debian X-server may have been confused as to whether it was headless or not and caused issues with nomachine (which tries to detect headless and start a virtual session).
The solution to this exact problem would be to disable the GUI and force a virtual session, per https://www.nomachine.com/AR03P00973 (dummy dongles won't work because the laptop's main display is not a standard plug).
In my specific case, I needed GUI access on the server at times so I couldn't use the above methods, and I could not remedy the problem with Debian, so I wiped the system and installed Ubuntu 20.04, which is more forgiving with graphics drivers and monitors. After setting up the Ubuntu system as similarly as possible to the Debian system and letting the proprietary nvidia drivers auto install, nomachine connected at the same resolution and worked perfectly, without the lag in small screen areas.
I have installed OpenCV on my desktop and laptop which they have Ubuntu 14, and i have some problem with its image viewer.
First of all when i type :
./facedetect --cascade="/usr/local/share/OpenCV/haarcascades/haarcascade_frontalface_alt.xml" --nested-cascade="/usr/local/share/OpenCV/haarcascades/haarcascade_eye.xml" --scale=1.5 [address of my image]
It shows my image with its image viewer , but it isn't resizabe on my desktop and it don't show control buttons at top of it on my laptop.
How can i fix these problem or can i change its image viewer ?
Opencv uses in many demo applications its own GUI (highgui), its features are limited and are platform-dependent. For example, I think that the "auto-zoom" feature that enables you to see the pixel values is available only on Windows. And, although recent versions added some Qt support to add somes features (buttons,...), the app has to be build to enable these features, and this is probably not the case in your example.
However, you can always edit the code of these apps (here, the facedetect app) so that it just saves the images on disk, instead of showing them on screen. Then rebuild. Or add yourself the buttons you want, see the manual.
I am running into hardware issues that perhaps someone here knows a workaround. I am using a PC and windows.
For several years I have been making interactive installations using video tracking: the Jmyron library in Processing, which has functioned marvelously for me. I use this set up: cctv type microcameras to a multiplexer, the I digitize this signal via a firewire cable to a pci card. Then Processing reads these quads (sometimes more) as a single window, and it has always worked (from windows xp all the way to 7). Then comes windows 8: Processing seems to prefer the built-in webcam to the firewire bus. On previous version of windows, the firewire bus would naturally override the webcam, provided I had first opened a video capture in Windows Maker, and then shut it down before running the Processing sketch. In Windows 7, which had no native video capture software, I used this great open source video editor called Capture Flux. The webcam never interfered. With Windows 8, no matter what I try, Processing defaults to the webcam, which for my purposes is useless. I have an exhibition coming up real soon, and there is no way I am going to have the time to rewrite all that code for Open CV or other newer libraries.
I am curious if anyone has had similar problems, found a work around? Is there a way of disabling the webcam in Windows 8 (temporarily of course, because I need it to be operational for other applications), or some other solution?
Thank you!
Try this:
type "windows icon+x" choose device manager (or use run/command line: "mmc devmgmt.msc")
look for imaganing devices, find your integrated webcamera
right click on it and choose disable - now processing should skip the device.
Repeat the steps to reenable the device.
Other solution would be using commands in processing:
println (Capture.list()); (google it on processing.org) this way you will get all avaliable devices and you can choose the particular one based on its name.
Hope this helps.
Is it possible to set Gimp'sPage Setup dialog to units other than inches? I have an image set to millimeter units, I have everything I can see set to millimeters, but when I select File->Page Setup to create a custom page size, the only option I have is inches.
I'm running on Ubuntu with Gimp 2.6.11.
No, it is not possible right now, and that is a bug on the application.
When you find issues like that, you can help further the tool development by filling up a bug report at http://bugs.gnome.org
I know it may seems just "huh?" how can this be unnoticed - the fact is that many open soruce tools, GIMP included are written on developer's spare times and I can tell you most actie GIMP developers don't use it for printing at all - therefore, the printing side of the tool is getting little attention.
I'm running DirectX application on the server (Windows Server 2003) and it does not have window (normally, running on PC, it has window). The issue is that I want to take screenshot of it from it (and save it to the png picture). When running on PC, this is working:
Surface backBuff = Device.GetBackBuffer(0, 0, BackBufferType.Mono);
SurfaceLoader.Save(fileName, ImageFileFormat.Png, backBuff);
But on server, the only thing I'm given is black picture (with right size).
Is it possible to take screenshot of directX app without window?
Thank you very much for answers
The solution is quite simple: running the app from script that is running under another user than IIS.